1542 commits

Author	SHA1	Message	Date
Erik	81a9d85a1d	fix(ui): spell-bar drag-reorder works — the per-frame rebuild was destroying the dragged cell (#354) ... Everything already existed — the drag payloads, the favorite wire pair (0x1E3 add-at-position / 0x1E4 remove, byte-confirmed against retail's Event_AddSpellFavorite @0x006A0F70 and ACE), the insert-shift state ops. The bug: lifting a favorite fires SpellbookChanged, the next per-frame Tick rebuilt the bar, the rebuild flushed and recreated every cell, and UiRoot's subtree-removal safety net canceled the in-flight drag whose source had just been destroyed — one frame after every lift, before any drop could land. The rebuild now defers for the duration of the drag gesture, and the drop ports retail's own -1-if-lifted-before-target index adjustment (SpellCastSubMenu::AddFavorite @0x004C7060) so final positions are byte-identical: insert-shift, not swap; drag-out still deletes (the lift's removal stands on a missed drop, retail's shape). The real-pointer-pipeline test fails against the pre-fix code with the exact cancellation and passes after; a discriminator pins that physical-item drop handlers reject the spell payload. AP-172 files the one presentation divergence (mid-drag reflow happens on release, not continuously) — renumbered from the agent's AP-171 draft, which collided with the same-day double-click row. #354 filed and closed. Clean-room complete solution: 11,541 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 18:28:47 +02:00
Erik	af1a1ef9e6	fix(ui): a coin change repaints the Items tab's cost sentence too — the post-buy purse no longer reads stale ... The money handler refreshed only the Buying/Selling tab summaries; the Items tab's "(you have Np)" tail rebuilt only on selection clicks. RefreshSelectionDisplay rides the same ObjectUpdated money path now. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-08 17:54:15 +02:00
Erik	4cfcc8b338	fix(ui): #353 — the stack-count entry takes the one-line draw path; RightAligned engages and the edit flicker dies ... RightAligned only applies on UiField's single-line renderer; the entry was falling into the multi-line path (ignoring the alignment AND re-scrolling its extents per keystroke — the reported edit flicker). A 14 px numeric entry is single-line by construction; OneLine = true routes it correctly. The 233 now sits flush against the slider per the authored HJustify=2. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-08 17:49:24 +02:00
Erik	d674b99f56	feat(ui): double-click-to-buy (AP-171, user-approved) + #353 toolbar text fixes — authored right-justify and two-line name wrap (Fable) ... Double-clicking a vendor shop item now buys through the Buy button's exact quantity/price path — retail has NO double-click-to-buy (the named table sweep's negative evidence stands); the user chose the addition explicitly and AP-171 records it. #353 (pre-existing, user-reported): the stack-count entry is AUTHORED HJustify=2 — right-justified flush against the slider on its own row — and UiField already supported RightAligned; nobody had honored the authored value. The name element is AUTHORED two lines tall (H=31, W=140): long names now word-wrap at the authored pixel width onto a second centered row via two stacked one-line labels reusing the existing centered draw path (WrapNameTwoLines: greedy word break, no hyphenation, second row clips like retail). Ten SelectedObjectController structure tests updated from single-label to first-label access. Lesson re-learned the hard way: the first "green" run used a stale TEST assembly (only the App project had been rebuilt) — the clean-room caught it, per feedback_stale_build_artifacts. Full App 4,329/3 and Core 4,381/1 verified green on properly rebuilt assemblies; the one transient Core Release failure did not reproduce and is noted on #351. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-08 17:42:02 +02:00
Erik	02b735ba4a	fix(vendor): evidence-based pass — max-first stack ceiling; the local player resolves never-animated MoveTo targets ... Both chains pinned by the live [vendor-diag] run (vendor-diag.log) after three code-reading rounds each failed: The split bar: ACE serializes descStackSize=1 for EVERY browse row (live wire, log 343-348) — the R1-era "ACE never populates desc" claim is retracted with the line quoted. Retail's vendor sites read pwd._maxStackSize directly (four sites, incl. UpdateItemsList @0x004c1ea0 stamping min(remaining, _maxStackSize)); ResolveAuthoredStackSize flips to max-first for its vendor-only consumers. Taper ceiling 1000, scarab 100, seed 1 for exempt. Pricing still reads the desc (per-1 values on ACE). Walk-to-use: the local player's getObjectA seam was bound to TryGetPhysicsHost, which resolves only INSTALLED physics hosts — a never-animated vendor has none, so TargetManager.SetTarget got null, the MoveToObject armed with zero nodes, and UseTime never dispatched. The log's natural=False completions were the user's own movement keys (retail-correct input-edge cancels); attempt 4 worked because the greeting animation had installed a host. RuntimePhysicsState gains the retail CObjectMaint::GetObjectA seam (bound canonical resolver with installed-host fallback); the graphical host binds the SAME lazy-minimal-host resolver every remote already uses — whose own doc comment names this exact never-animated hazard. The reservation release was already correct (2b premise refuted with evidence); the production-wiring invariants are now pinned by four new tests including the pre-fix pathology as a permanent sabotage control. AP-169 rewritten a second time, honestly. The [vendor-diag] probe family (ACDREAM_DUMP_VENDOR) lands env-gated for future live triage. Clean-room complete solution: 11,536 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 17:17:04 +02:00
Erik	d003449bb4	fix(vendor): re-gate residuals — MaxStackSize is the stack operand, wire-authored use radius, purse summaries ... R1 the split bar's operand is the item's authored MaxStackSize — three retail sites read pwd._maxStackSize directly (InqListSlotCount pc:200052, buy-button cases pc:203996/204086) where ACE never fills the desc stack and standard stock is unlimited. Threaded StackSizeMax end to end with one shared resolver; the two literal _maxStackSize sites are now byte-exact; AP-165 retired, AP-169 corrected. R2 walk-to-vendor never opened because GetUseRadius used an UNCITED 3m Creature heuristic as the local stop distance while ACE's poll demands the authored radius (default 0.6 m) — the walk stopped and the Use fired far outside acceptance. Now reads the wire-authored spawn UseRadius with ACE's exact fallback; heuristic constants deleted. A first sabotage attempt was non-discriminating (coincidental 0.6) and was corrected — the discriminating version is what landed. R3 the Buying/Selling purse summaries ("Buying %d %s worth %hsp" / "You have %hsp") recovered from the binary data segment where BN mis-attributes the Buy-side literal; wired to staging and money changes on the four authored text elements; AP-166 narrowed to the pending-sell highlight. Clean-room complete solution: 11,528 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 15:23:10 +02:00
Erik	68568a3a59	fix(vendor): grand-gate findings — wire-truth container counts, the live split bar, arrival-gated use, prepend-order race ... Four live findings, each with the paper-verification failure named: G1 the container-capacity guard counted containers by a local type/capacity heuristic that over-classifies ordinary items; retail buckets from the wire's ContainerProperties at insert. Now reads ClientObjectTable's existing ContainerTypeHint (AP-168 narrowed to the shop-stock half; a pre-check must never false-block). G2 the amount bar never showed live because ACE never sets StackSize on browse listings — DescStackSize is null for every real vendor item and the C4 paper test hand-set the field, bypassing the materializer. The materializer now falls back to the packed supply count (AP-169, ACE adaptation); the new test drives the REAL materializer. G3 an out-of-range Use now dispatches ON ARRIVAL (pickup's shape): ACE's HandleActionUseItem only opens the vendor when the Use finds the player in range — a click-time send is greeted and dropped (AP-170, ACE adaptation; retail's server walks the player, ACE does not). G4 bought items appended because ACE's placement echo (UIQueue) can beat the CreateObject (SmartboxQueue) — cross-queue, no ordering guarantee — and the early echo was silently dropped. ClientObjectTable now stashes unresolved placements and replays them at Ingest: buys land at the retail list head. No register row — this RESTORES parity. Clean-room complete solution: 11,521 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 14:03:57 +02:00
Erik	c68ad1e646	fix(vendor): 6b/6c review corrections — pre-send guards, accumulating staging, trade-note exemption, drag-over tab switch, full-stack sells ... All thirteen findings, each anchored in recovered bytes or pc reads: Buy All now runs retail's four PRE-SEND guards in order (pyreal and alt-currency affordability, container and item slot capacity; strings recovered from .rdata at 0x007b57b4/0x007b5750) — a rejected batch can no longer destroy the staged list. Staged adds ACCUMULATE with the 5000 cap ("I can't possibly sell you that much!..." @0x007b59d8) and the shop rows decrement/restore per RemoveFromShop. The max-value sell rejection exempts trade notes — the raw bytes at 0x005d1add are `not` (bitwise), not the pseudo-C's misleading `!`, and the early ret skips the min check too. BF_RETAINED gates selling end to end (the bit was already on ClientObject; AP-164's three claims were all false once traced — RETIRED). Dragging over the vendor window auto-opens the Selling tab per UpdateDragOver — with a correction to the review's own citation: token 0x100000cd is the SELLING page, the guard is "don't reopen the current tab." Sells are full-stack-only (three retail sites; "Cannot sell part of a stack" @0x007b57ec) and Sell Item acts on the global selection unconditionally. The confirm string gains its byte-true trailing '?', dies with the session, staged-row highlights repaint, dead guids unstage with retail's shopping-list notice, and move-to-use no longer walks to targets the dispatch would refuse. AP-162 narrowed, AP-164 retired, AP-167/AP-168 filed honest. Clean-room complete solution: 11,508 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 12:50:28 +02:00
Erik	92ea3977b6	feat(vendor): Slice 6b/6c — move-to-use, buy staging, selling; the vendor arc is functionally complete ... C1 an out-of-range Use now approaches first via the existing client-predicted BeginApproach (Pickup's far-range shape mirrored; retail's ItemHolder::UseObject @0x00588A80 has no range check and the dispatch stays immediate). C2 Add-to-List stages into the Buying tab via VendorStagingList (RemoveProfileFromList's two shapes, pc:200497-200537), Buy All sends ONE batched 0x005F and flushes staging on send exactly as retail does (SendShopEvent -> Flush, pc:204075-204076 — not UseDone-gated), and X-close over a non-empty staging list shows retail's confirm string recovered verbatim from the binary data segment (0x007b5bd8) through the existing dialog factory. C3 the Selling tab's list is the sole drop target (retail's single IsAncestorOfMe gate, pc:204229-204246); VendorSellAcceptability ports InqAcceptability with all rejection strings recovered verbatim from the raw data segment; the sell side prices with BuyPrice (retail's inverted naming: what the vendor PAYS) and 0x0060 carries no trailing currency field, unlike Buy. C4 the status-bar reproduction test PASSES against the production toolbar mount — retail's toolbar shows count + name with the split bar and NO price parenthetical (that figure is the vendor row's own cost text); no code change, the live gate referees. C5 pack order verified correct, untouched. Register: AP-161 narrowed to its two pre-existing cosmetic gaps; AP-162 extended over Buy All; AP-164 (non-sellable bitfield unmodeled), AP-165 (DescStackSize for _maxStackSize in the removal test, bounded), AP-166 (purse text + pending-sell highlight cosmetic) filed. Clean-room complete solution: 11,482 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 11:43:11 +02:00
Erik	33b45ee581	fix(ui): vendor dropdown polish — authored arrow-cap with open/closed flip, downward popup, left-aligned rows ... Three gate findings, each settled by authored data rather than invention: the button face is retail's two-piece assembly and the 17x19 arrow-cap 0x1000034E now renders with its authored Normal(closed)/Highlight(open) states; the popup direction is an AUTHORED attribute (UIElement_Menu::Open pc:120210-120252 — bool attr 5, chat authors upward=true, the vendor menu authors nothing and defaults downward), so both menus are now byte-faithful with no special case; and the 19/20px text indents were chat-specific checkbox/LED clearances the vendor rows don't author — measured against the live retail font, "Spell Components" overflowed by 11px and now fits with 8px to spare. Chat's menu defaults are bit-identical and its tests untouched. AP-161's arrow-cap note closes. #351 files the pre-existing FarLoad Debug flake (three sightings today, never in clean-room Release). Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 10:59:59 +02:00
Erik	5224e43890	fix(vendor): gate-findings pass — the X button HIDES like retail, clicks return, the dropdown scrolls, pyreal suffix, staged-tab slots ... The user's connected gate found five issues; each fixed at the root: G4 (the discovery): retail's vendor X button calls only SetVisible(0) (pc:204147-204182) — the SESSION stays open and re-using the vendor lands on the same-session refresh; the range watcher remains the sole real close. Our port invented a full teardown on X, which is exactly why reopening died. The Runtime fixture proves the wire dispatch was never the problem; ACE has no already-open short-circuit. G3 (regression from the drag-suppression fix): denying IsDragSource also dropped press capture, so clicks fell through to window-drag. UiItemSlot.HandlesClick now claims presses for any occupied cell independent of drag eligibility — clickable and draggable are separate concerns. G5: the authored popup 0x21000043 is ONE scrollable column with a real scrollbar subtree (live-dat scan: ListBox 0x10000350 + scrollbar 0x10000351), not a 3x6 grid. UiMenu gains an authored-driven Scrollable mode (wheel, thumb drag, track paging, up/down buttons); chat's menu is untouched and its ten tests prove it. G1: retail's cost format is "%s %hsp (you have %hsp)" — the p after each %hs is a LITERAL pyreal suffix the port swallowed as part of the specifier. Restored. G2: the Buying/Selling pages' authored lists (same cell template as Items) get the empty-slot fill, presentation-only until staging. Clean-room complete solution: 11,390 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 10:29:39 +02:00
Erik	58c8de264e	fix(render): #350 — the shadow ledger's lifetime counters are 64-bit; the 2h42m overflow is closed ... RenderDeltaApplyResult's nine counters accumulate for the lifetime of a world generation (the cumulative sum is never reset in place) yet were int where every sibling lifetime counter in the same class was already ulong/long. A 2h42m single-generation session (login to crash with zero portals) overflowed one through ordinary per-tick churn from SynchronizeActiveSources' two call sites per frame. Introduced 0eb66485 (2026-07-24); first reached by the vendor buy gate because parking at a shop for hours produced the project's first multi-hour unbroken generation. The vendor materializer was exonerated by routing analysis (shop-item Ingest/Remove reaches inventory deltas only, never the render journal). Widened to long; the per-tick builder stays int and widens implicitly; the arithmetic stays checked. All 68 render-shadow tests green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 10:29:39 +02:00
Erik	3c9fc57adb	fix(vendor): Slice 6 review corrections — ownership-checked retire, live slider display, drag-proof shop rows, hardened buy reservation ... All nine findings from the buy-arc review, at root: F1 the materializer's retire pass re-checks ownership (guid->vendorId map; remove only while the live object's ContainerId still equals the recording vendor) — buying a player-sold UNIQUE no longer deletes the item you just purchased; the discriminating reparent-then-refresh test pins it. F2 the cost/name display subscribes to the live split state and shares ONE quantity computation with Buy (retail re-renders per slider tick: RecvNotice_StackSliderChanged 0x004C4500) — the sentence and the charge can no longer disagree. F3 shop rows never mint drag payloads (UiItemSlot.AllowDragSource gates both IsDragSource AND GetDragPayload — the second gate was caught by this pass's own test). F4 sendBuy reports whether anything was sent; a null-session buy cancels the reservation instead of leaking BusyCount forever. F5 the retire loop snapshots, isolates per-guid observer failures, and clears its tracking in finally and Dispose — teardown convergence can no longer wedge. F6 auto-select is retail's unconditional first-filtered-item shape (pc:201180-201184; the survival-check was our invention and the comment claiming otherwise is corrected). F7 non-stack buys clamp to quantity 1 locally (BuySingleItem pc:201669). F8 the Add button is hard-disabled until staging exists. F9 AP-161/162/163 rewritten to the post-fix reality. Clean-room complete solution: 11,378 passed / 4 skipped / 0 failed. The #350 render-ledger overflow observed this session is under separate investigation and is NOT addressed here. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 23:12:50 +02:00
Erik	97cf873870	feat(vendor): Slice 6 buy arc — shop items are real objects, vendor selection is THE selection, and Buy works (0x005F) ... Three ordered pieces in one landing (the shared controller/composition files carry all three; the internal order was 6.1 -> 6.2 -> 6.3): 6.1 VendorShopItemMaterializer diff-merges the shop list into the live ClientObjectTable on VendorState transitions (so client-local close and session teardown retire the entries too) and never claims a guid it did not add — ACE's UniqueItemsForSale can re-list a guid a player once held (AP-163 files the collision-skip; no retail counterpart traced). Right-click examine on shop items now routes through the ordinary appraisal path — the 5.4 F7c blocker dissolves with the table entries. 6.2 SelectionChangeSource.Vendor: row clicks, auto-select, and examine all flow through the canonical SelectionState; the status bar and the existing byte-faithful StackSplitQuantityState slider light up unmodified. VendorSplitPolicy is the single 0xDC41CB0 mask owner; the slider VALUE seeds to 1 for exempt items while maxSplitSize keeps the stack (the splitSize/maxSplitSize distinction, research §B.3). Selection clears at retail's actual site — VendorItemsUI::RemoveFromShop (pc:202848), not a CloseVendor-level clear that does not exist. 6.3 BuildBuy (0x005F): vendorGuid, count, (i32 amount, u32 guid) pairs, and the trailing alternateCurrencyId the REAL client sends (CM_Vendor::Event_Buy pc:689288) though ACE's reader ignores it. TryBuy rides the EXISTING J5.2 one-request-at-a-time reservation and completes on UseDone; the Buy button disables while a request is in flight. The reconciliation round-trip (money property update, inventory CreateObject, ApproachVendor refresh -> panel rebuild) is proven by a synthetic-inbound test against existing machinery — no new owner. Register: AP-161 narrowed (selection + examine residuals close; staging/Sell remain; double-click-to-buy confirmed ABSENT from retail with negative evidence cited — we match retail). AP-162 files the conscious no-client-side-affordability-precheck deferral. Clean-room complete solution: 11,368 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 20:28:26 +02:00
Erik	e602f84be2	fix(ui): Slice 5.4 review corrections — the dropdown renders from its authored popup, retail cost semantics, auto-select, icon overlays ... All nine review findings closed at root (one sub-item consciously deferred): F1 the category dropdown now draws: sprites/fonts wired and the popup geometry read from the vendor menu's own authored popup LayoutDesc 0x21000043 (root 0x1000034F — correcting the review's 0x1000014F transcription) per UIElement_Menu::MakePopup (pc:120705); chat's menu is untouched and its tests prove it. The new test drives selection through the REAL open/hit path the review flagged as bypassed. F2+F3 the selected-item cost display ports VendorItemsUI::UpdateItemsUI verbatim: quantity via the 0xDC41CB0 split-size mask (whole-stack for ammo, per-unit for groceries/components; mask lives at the toolbar SEEDING site pc:198784), plural names with retail's fall-back-to-singular (pc:409056 — correcting the review's "name+s" guess), full cost sentences with comma grouping and the player's coin total, and Buy/Add buttons that disable without a selection. F4 category switches auto-select the first filtered item (pc:201180). F5 icon underlay/overlay/effects + plural name forwarded from the already-parsed wire fields through VendorShopItem to the icon composer. F6 a DIFFERENT vendor opens on its own first category; same-vendor refresh preserves per the clamp. F7 scroll resets on rebuild and authored empty slots fill; the right-click examine route is consciously DEFERRED (shop items are not in ClientObjectTable and the appraisal panel hard-requires it — documented, not faked). F8 VendorState.Apply's fanout gets the same per-listener isolation as Close/Reset. F9 AP-110/AP-161 wording corrected ("quantity-correct pricing") and AP-161 rewritten to exactly the remaining conscious gaps. Clean-room complete solution with the #348 cursor fix in the same tree: 11,334 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 18:26:17 +02:00
Erik	9d3df5f627	fix(app): #348 — cursor switches ride a process-lifetime native cache; the per-flip Win32 handle leak is closed ... Silk's per-mouse ICursor recreates the native Win32 cursor on every Image assignment; a per-frame cursor alternation (the pick cursor flickering between kinds while hovering an ANIMATED NPC — exactly the stand-at-a-vendor posture) allocated a fresh USER handle each flip until CreateCursor died with "Not enough memory" and took the render loop with it (vendor-gate.log, exit 82 — surfaced as one clean stack by #343's fix, as designed). GlfwCursorCache restores retail's own shape: each distinct MediaDescCursor is created ONCE for the process lifetime (glfwCreateCursor, rejected media cached as permanent misses) and switching is an O(1) zero-allocation glfwSetCursor. The AP-72 missing-art standard-cursor fallback rides the same cache (Arrow/Hand/Crosshair/IBeam; anything else keeps the Silk path). Graphical hosts attach after the native window exists; tests and windowless hosts keep the Silk path untouched. RetailCursorManager's dedup and PlanApplication logic are unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 18:26:17 +02:00
Erik	c721830e71	feat(ui): Slice 5.4 — the authored vendor browse panel (LayoutDesc 0x21000012) ... The vendor window is retail's own: LayoutDesc 0x21000012, root 0x100000B7, found by enumerating all 101 layouts for the one containing both known tab controls and clinched by the root's Type 0x10000017 — the literal UIElement::RegisterElementClass id for gmVendorUI (pc:202075). Discovery evidence and the D0 read live in the research doc's new §B.4. D0 corrected two assumptions: retail's category "tabs" are a UiMenu DROPDOWN fed by a hardcoded 18-row ordered category table (ported bit-for-bit against our ItemType enum; list always scoped to exactly one category, first-present wins, selection preserved across refresh per retail's clamp), and the layout authors THREE tabs — Items (browse, this slice), Buying and Selling (staged-transaction review, Slice 6) — decision 4's "browse/Buy tab" names the Items tab retail's mode-2 OpenTab opens. The non-default tabs render and switch pages but stay inert, fenced in comments. VendorUiController mounts Items: category dropdown, icon-cell item row with the retained scrollbar, per-unit retail pricing via VendorPricing.SellPrice (the vendor-stock path VendorProfile:: VendorSellPrice feeds), name/cost on selection. The panel is a pure projection of VendorState — opens on populate, closes on clear; the close button's VendorState.Close() is its only permitted mutation. Nothing on the wire. AP-110 narrowed (vendor leaves the absent-panels list); AP-161 files the precise Slice-6 remainder (Buying/Selling unwired, Buy/Add buttons, InqAcceptability). Twelve controller tests on a real-dat fixture. Clean-room complete solution: 11,323 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 17:00:21 +02:00
Erik	9796d71522	feat(runtime): Slice 5.3 — RuntimeInventoryState owns the vendor browse session ... The sole VendorState joins the J4.2 inventory owners: populated by the new 0x0062 ApproachVendor route (parse via VendorApproach, wire-to- domain mapping at the routing seam, silent-drop on malformed like every sibling), borrowed by both graphical and headless hosts, and torn down through the EXISTING ExternalContainer reset stage — session reset, portal-out, and logout all funnel through the one mechanism. Close is client-local per retail (nothing on the wire): a range watcher rides the existing per-advanced-frame publishMovement callback, using the vendor's own authored UseRadius (ACE's 0.6 m fallback when absent). The dormant ItemInteractionController ActiveVendorId seam is finally wired as a live delegate — real id while open, 0 the moment the session clears. AP-160 filed in this same commit: the watcher measures plain 3D center distance rather than retail's cylinder-gap, because Runtime has no per-NPC collision radius/height source; bounded sub-meter, client- local UI only. Twelve Runtime tests: populate/field mapping, vendor replacement, range clear + within-range retention, all three generation teardowns, the ActiveVendorId seam, malformed-event drop. Clean-room complete solution: 11,302 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 15:37:12 +02:00
Erik	6c6664a685	fix(app): #343 — a wounded render loop defers the native release instead of throwing over the real failure ... Root cause pinned by IL-decompiling Silk.NET.Windowing.Common: ViewImplementationBase._inRenderLoop is set at DoRender/DoUpdate entry and cleared ONLY on normal return, so a throwing frame callback leaves it armed forever and any later Dispose -> Reset throws "You cannot call Reset inside of the render loop", exit 82, replacing the original wounding exception in the report. The fix mirrors Silk's own bracket exactly: GameWindow._renderLoopArmed set at OnUpdate/OnRender entry, cleared only on their normal return — deliberately NOT in a finally, so it tracks the wound the same way Silk's private field does. ReleaseNativeWindow checks it before disposing: armed -> best-effort Close() (swallowed so it can never become the reported failure), no Dispose, and a new terminal status CompleteWithDeferredNativeRelease with Error kept null — the original exception stays the primary report. Healthy paths (OnClosing's in-loop completion, Run()'s tail release) are byte-unchanged, and the new PublishNativeWindow parameters default to null so every existing caller and test behaves identically. Sabotage: disabling the armed-check flipped the deferral test to Expected CompleteWithDeferredNativeRelease / Actual Complete — the guard is what the test exercises. Clean-room suite 11,262 / 6 / 1, the 1 being #340's documented load flake (passed standalone; second recorded firing noted in its entry). Queue: #344 done, #343 done; next #345's instrumented mechanism session, then #341's boundary hunt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 10:28:29 +02:00
Erik	52bdf4df71	fix(world): #344 — a mid-teleport world-frame disagreement defers the projection instead of crashing ... During a portal transit the two world-frame owners legitimately rebase on different edges (Runtime at TeleportAdvanced, streaming only after old-window retirement), and a spawn projection landing in that window hit the #283 invariant as an unhandled render-path throw — the crash the user hit entering a dungeon. The guard's check is unchanged; only the disagreement RESPONSE is discriminated on the canonical transit authority (RuntimeWorldTransitState.IsTeleportActive, the same field the App layer already reads for portal-in-flight): in transit -> the materializer's existing "not yet" return, parking the projection on its established retry rides (OnLandblockLoaded's re-attempt loop, whose ordering guarantees agreement on retry because the recenter coordinator adopts the new origin BEFORE unblocking new landblock loads — verified at source; plus OnPosition recovery and OnAppearance). Outside transit -> still throws: genuine corruption stays loud. The implementer explicitly ruled out riding the Runtime placement pump, which would have acknowledged-and-discarded the completion receipt and silently dropped the entity forever. Sabotage: removing the discriminator reddened the pre-existing #283 throw tests as well as the new not-in-transit test — the sabotage defeats the original contract, not merely the new coverage. Four new tests cover defer, defer-then-agree-then-succeed (projected exactly once), throw-outside-transit, and the agreeing pass-through. Clean-room suite: 11,261 passed / 6 skipped / 0 failed. #346 filed for a sixth, distinct load-sensitive allocation flake observed during the runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 10:07:45 +02:00
Erik	205379c6d6	fix(streaming): #339 — a packed EnvCell geom id no longer misroutes into the 32-bit prepare arm ... The reveal hang (three live occurrences: portal-space, login twice) was an unhandled OverflowException on the render frame's readiness evaluation: EnsureRenderDataReady found a packed 64-bit EnvCell geometry id OWNED but DESCRIPTOR-LESS — the release path removes the descriptor while render data parks on the LRU, IncrementRefCount restores ownership on a revisit, and the scheduler's PrepareEnvCellGeomMeshDataAsync has not yet re-registered — and fell through to the Setup/GfxObj arm, whose checked((uint)id) cast threw. After that the reveal was never evaluated again. The fix corrects the TYPE DISPATCH rather than suppressing anything: packed ids (bit 33, GetEnvCellGeomId) answer "not yet" in the acquire-to-prepare window — the true answer, since the scheduler re-registers on the same landblock build — and PrepareMeshDataAsync's blind cast becomes a typed, loud invariant failure naming the id kind and the issue, so a future caller repeating the confusion gets a diagnosis instead of three live hangs. Validation: the crash was DETERMINISTIC at login cell 0xA8B4002F (two consecutive hard failures); with the fix the same login revealed cleanly and a full session — 16,585 entities, five portal generations, the user-passed Session-B dungeon gate — ran with zero overflows and zero guard fires. Clean-room suite: 11,253 passed / 6 skipped / 0 failed. Found because the Session-B gate launch finally captured the stack the earlier #339 hangs never printed. #343 (the wounded loop's Reset-in- render-loop shutdown) and #344 (the mid-teleport world-frame race the same evening surfaced) are filed separately and unfixed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 08:37:43 +02:00
Erik	9671af0273	fix(physics): S2 — static publication emits authored Spheres as Spheres (AP-155 narrowed) ... Both static sites (LandblockPhysicsPublisher, the headless-only LandblockPhysicsContentBuilder) emitted an authored Setup Sphere as a base-anchored Cylinder of radius r and height 2r. The live path emits a Sphere for the same data, so the same object collided differently by arrival route, and the narrow phase met a flat cap where retail meets a curved surface. Both sites now mirror ShadowShapeBuilder.FromSetup's Sphere block exactly. Combined Opus review: PASS. Its numeric verification of the dispatch test's geometry (head-sphere clearance 0.201 m for the true sphere; the cylinder counterfactual inside by 0.10 m XY with the Z band overlapping) is what makes the discrimination claim more than a sabotage anecdote, and its F8 finding is applied: the test now carries a POSITIVE control — aiming straight through the boulder's centre must block — so a membership/seed regression can no longer masquerade as a curve-hit pass. F4 applied: CylHeight is asserted, not inferred (the C4 lesson). F3 applied: the deleted Quaternion.Inverse base composition is recorded as internally coherent for the old cylinder's world-Z axis — the defect was the shape TYPE, not that rotation math. The review also verified the deleted-cylinder blast radius: the F2 overlay's drawn span is IDENTICAL for both shapes (old [c-r, c+r], new [c-r, c+r]); the flood sphere's centre rises by exactly r, which cannot change outdoor membership (XY rectangle) and lands the indoor half on Session B's dungeon gate alongside S1B; and the sphere-branch flood is now pinned uncapped by a genuine eleventh-shape A/B test. PublishStaticCollision — the headless static path — gains its first test ever. AP-155 is NARROWED, not deleted (review F13): the has-BSP source split (entity.MeshRefs vs setup.Parts + AnimPartChanged) survives and keeps the row active. The shared-primitive-emitter refactor that would make route independence a compile-time property is the filed follow-up (review F20). Population: 3,506 of 5,935 installed Setups, structurally equal to AP-157's third-branch count (byte-identical classifier — three independent routes agree: 3,605 - 99 = 3,506). Clean-room suite at implementation: 11,253 passed / 6 skipped / 0 failed on landed S1B. Post-review-hardening: Publisher tests 25/25, Content tests 2/2, both green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 08:07:02 +02:00
Erik	55b07f6a62	refactor(physics): hoist the live-entity collision builder to Runtime (#330 groundwork) ... LiveEntityCollisionBuilder and LiveEntityDefaultPoseResolver move from AcDream.App.Physics to AcDream.Runtime.Physics with no behaviour change — diff-verified byte-identical shape math by both review lenses. The Build signature's App-record parameter is replaced by presentation-free primitives with identical guard semantics, INCLUDING the FinalPhysicsState read the contract had missed and the implementer surfaced rather than dropped. Visibility stays internal: Runtime's existing InternalsVisibleTo grants already cover every consumer, so the implementation's public widening is reverted per the architecture review's finding 11. The registration WIRING is deliberately WITHHELD. Both Opus lenses failed it, converging: a shadow registered at spawn freezes there (RuntimeRemotePhysicsUpdater is Runtime-homed but App-driven — nothing headless ticks it), so a walking NPC becomes a phantom obstacle at its spawn point while the real NPC still passes through the bot; three of five shadow-lifetime edges leaked (pickup leaves a permanent invisible collider, supersession orphans a duplicate, generation reset never unregisters and the K-ledger convergence oracle only checks retained shadows AFTER disposal clears them); and headless cannot resolve BSP collision assets at all, so doors and chests would still be walk-through. The frozen-shadow root was the SESSION LEAD's contract error (fact 3), not the implementer's. #330 stays OPEN, rewritten as the seven-point scope map the reviews produced — the honest overnight deliverable is that map, not a half-mechanism carrying new divergences. Suite 11,235 passed / 4 skipped / 0 failed (the withheld seam's two tests account for the delta from the implementation run's 11,237). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 01:49:13 +02:00
Erik	49a7e90652	probe(physics): ACDREAM_PROBE_SUPPORT + ACDREAM_WIRE_MESH — separate #337's three candidates ... The user is wedged at the top of Neftet rock plateaus, jumps sink into the mesh, and a corpse falls straight through. ACDREAM_PROBE_REACH already ruled out its own domain: blocked=0, every candidate tested-ok. Three candidates remain — terrain support, a collision mesh not where its visual is, or the transition wedging on an unobstructed path. ACDREAM_PROBE_RESOLVE alone cannot separate them. It prints a three-value contact-plane token, no plane normal, no plane height, no terrain sample and no plane provenance, so all three produce the same line. Two additions: [support] — one line per resolve for EVERY body, not just the player. A corpse is a plain physics body with no player-specific logic, so its fall-through is the cheapest available control on "movement code vs geometry data", and it is invisible to any player-filtered probe. The line samples the outdoor terrain INDEPENDENTLY at the body's own out-XY and prints the contact plane's own height at that same XY. Two heights at one point make support=terrain / object / none a measurement rather than an inference, and cpSrc= names the site that asserted the plane so provenance and classification cross-check. [geom] — once per GfxObj that comes near a mover: the object's physics-BSP vertex cloud against its visual mesh AABB in the same local frame, through the same prepared accessors the resolver queries. verdict=coincident REFUTES the working hypothesis for that object outright; no-physics-bsp / empty-physics-bsp / displaced / extent-mismatch each name a specific data defect. Built to refute, not to confirm — two diagnoses on this defect's lineage have already been refuted by measurement. ACDREAM_WIRE_MESH upgrades the existing F2 overlay, which drew a broadphase proxy cylinder for BSP objects and so could not answer the question at all, to the real physics-BSP polygon edges (cyan) beside the visual mesh box (magenta) and the terrain surface (yellow). Own class per code-structure rule 1. The provenance latch lives on PhysicsDiagnostics, not on CollisionInfo. Two fields there first — the obvious home — broke the flat/graph differential referee and the scratch-reset poison test, both of which compare CollisionInfo member-for-member. Teaching either to skip a member is a one-line green fix that puts a permanent hole in a referee whose whole job is comparing everything. Captured as feedback_probe_state_off_compared_types. Seven tests cover the support classifier's boundaries: a wrong classifier does not fail to answer, it answers confidently wrong. Gates: Release build 0 errors; complete suite 11,225 passed / 4 skipped / 0 failed from a cleaned tree — baseline 11,218/4/0 plus exactly the seven new tests, skips unchanged. Issue #337 filed with the symptom set, what is ruled out, and a table of what each possible output means. All of this is TEMPORARY and recorded for stripping with the physics-probe family. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 19:49:59 +02:00
Erik	13fcf38138	fix(physics): port retail's find_bbox_cell_list outdoor extent walk (#334) ... acdream had never implemented retail's SECOND cell-membership algorithm. CPhysicsObj::calc_cross_cells @0x00515230 tests HAS_PHYSICS_BSP_PS at 0x00515285 and jumps (0x0051528f jne 0x515305) to find_bbox_cell_list @0x00510fc0 for a BSP-bearing object; everything below that jump is the OTHER algorithm, CObjCell::find_cell_list, and that is all we had. Every object, BSP-bearing or not, was routed through it. That path's outdoor expansion is a HARD CAP of one cell in each direction. CellTransit.AddAllOutsideCells computes minRad = radius, maxRad = 24 - radius and adds at most the eight neighbours of the sphere's own cell, so for any radius >= 12 m both boundary tests are unconditionally true and the result is exactly 3x3. Widening the radius or adding a second sphere is mechanically incapable of adding a tenth cell. The user's live probe measured the consequence directly: standing inside a Neftet formation, inCell=2 exempt=2 reached=0 -- the geometry was not a candidate at all. The port. AddAllOutsideCellsFromParts is CLandCell::add_all_outside_cells @0x00533360 plus add_cell_block @0x005331d0: base landcell from the FIRST part's own adjust_to_outside, baseX/baseY within-block, each part's authored CGfxObj::gfx_bound_box re-fit through all eight corners (BBox::LocalToGlobal @0x005b2120), floor(v / square_length) where square_length = 0x7c920c = 24.0f, four accumulators seeded to zero, ONE rectangle unioned across all parts, FILLED, in GLOBAL lcoords so it crosses landblocks freely, clamped only to [0, 0x7f8). BuildShadowCellSetFromParts is find_bbox_cell_list's worklist. RegisterMultiPart dispatches on the same flag retail does, and BuildFloodSpheres' BSP arm is deleted rather than left unreachable. Disassembled from the PDB-paired 2013-09-06 binary, not read from Binary Ninja: BN mis-renders four separate constructs inside add_all_outside_cells alone -- a dropped `and eax,0xffff` on baseX, a neg/sbb/and select shown as identically zero, a wrong get_landcell argument, and both x87 flag tests as `unimplemented {test ah}`. ShadowPartGeometry pairs the BSP root sphere with the authored box so no resolver can answer one and leave the other call site to synthesize a substitute -- the AP-156 invariant applied a second time, since that split is what produced AP-156 and then this. The box comes from FlatGfxObjVisualBounds, already computed by exactly CGfxObj::init_end's algorithm and already in the prepared package: no bake change, no DAT re-read. Cost, measured over the installed DATs before any code was written: 1,258 physics-BSP GfxObjs, cells/object p50 4, p90 4, p99 12, max 49. The port is CHEAPER than the old 3x3 = 9 for 98.97% of them. Row totals (shapes x cells) over all 1,031 landblocks with BSP owners fall 97,173 -> 15,607 (0.161x); dense Arwic 0xC6A9 falls 342 -> 43. One landblock more than doubles. Precondition confirmed before pinning any expected cell set: 0x010046D8's box is 96 m x 96 m about cell (2,2) = 0x87640013, which independently corroborates the 3x3-centred-there diagnosis, and its rectangle does contain 0x87640011 and 0x87640019 -- the two cells the probe measured empty. Register: AP-156's outdoor half CLOSED and its risk column CORRECTED (it read "extra broadphase candidates, never a missed one", which generalised the indoor direction to the whole row and is why #334 sat inside it unnoticed). AP-159 + issue #335 file the unported indoor arm; AD-49 records the seed-time rectangle. Issue #336 files a fourth load-sensitive test flake seen once during the gate. Ten tests, every one sabotage-verified in both directions across eight mutations (dispatch, 8-corner refit, floor-vs-truncation, union-vs-per-part, map clamp, adjust guard, landblock clamp, box-path-for-everything). The strongest is an installed-DAT replay of the user's own probe evidence. Suite 11,208 -> 11,218 passed / 4 skipped / 0 failed; the +10 is exactly the new tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 19:07:06 +02:00
Erik	e6457cc849	fix(physics): close the AP-156 fix review — real containment oracle, type-level invariant, AP-158 ... Both review lenses PASSED; this is the cleanup, not a rescue. Evidence: docs/research/2026-08-06-ap156-review-closure.md (the review itself is committed alongside it as the received artifact). R1 — the load-bearing containment test could not fail. Its truth and flood values were two hand-copies of the same expression over the same part set, so the shortfall was algebraically identically zero for any DAT input. The oracle is now PHYSICS-POLYGON VERTICES — a different DAT field from the bounding sphere the builder emits, so the two sides can genuinely disagree. Sabotage-verified three ways after full cleans: dropping the bounds centre in production reddens it (428 Setups, worst 35.869 m on 0x0200129A, matching an independent out-of-repo sweep exactly); dropping only the scale on the centre reddens it (326); and corrupting the TEST's own bounds oracle reddens it (467) where under the shipped oracle that same corruption was invisible by algebra. Renamed accordingly. A6's stale "cap control" comment corrected: that loop is the test's own uncapped re-implementation and cannot observe a cap regression — the cap is covered in Core. R2 — the population was understated. 172 is AP-152's DISPATCH population; AP-156's is 530 BSP-bearing Setups, of which 525 have a flood sphere move and 428 fail vertex containment before the fix (412 at a 1 cm tolerance — the review's figure; the gap is 16 Setups between 1.4 mm and 10 mm, real geometry). 0 fail after, at any tolerance down to zero. Corrected in the AP-156 row, the section-3 header, the C5c handoff and two test docstrings. Dated review artifacts are left as written — "170 of 172" was correct for what they measured, and rewriting evidence to match a later measurement loses provenance. A1 — BoundsCenter = default reopened at the type what the commit closed at the seam. Dropping the default alone would NOT have closed the review's own scenario (a copied Cylinder call site would write Vector3.Zero explicitly and stay green), so ShadowShape's constructor is now private and BSP shapes are built only through ShadowShape.Bsp(..., FlatCollisionSphere localBounds), which takes radius and centre as ONE value and scales them together. There is no expression a caller can write that carries one and drops the other. 22 construction sites converted; the same sabotage now reddens 5 Core tests where the review's sabotage A reached 4, because both BSP producers share one scaling path. A2 — #333 is real and bigger than filed, and its retail question is answered. I disassembled CObjCell::find_obj_collisions @0x0052b750 from the PDB-paired binary myself (check_exe_pdb.py MATCH) rather than inheriting the claim: its only early-out is sphere_path.insert_type == INITIAL_PLACEMENT_ INSERT, then it calls FindObjCollisions on every unparented non-self shadow object UNCONDITIONALLY. Retail has NO distance pre-filter, so acdream's "+ movement + 2f" reach filter is an invention with no register row — filed as AP-158, carrying the disassembly, the F_EPSILON = 0.0002 m contrast, and the measured blast radius (118 of 477 unique installed physics-BSP GfxObjs exceed its ~2.5 m budget, 46 exceed 5 m). Active AP rows 109 -> 110. Recorded prominently in three places a reader will hit: TALL PROPS MAY SHOW NO VISIBLE CHANGE UNTIL #333 LANDS, and a null result at the connected gate is EXPECTED, not evidence against AP-156. LOW items. R3: the comment claiming the cited evidence justified the whole cap line is corrected, but int.MaxValue on the sorting-sphere branch stays — capping at 1 would take Spheres[0], and retail's one sphere is CSetup::sorting_sphere, a different DAT field; capping keeps the wrong field AND flips the substitution under-inclusive (#98/#168 direction). AP-157 already owns it. R4: acdream scales the flood sphere where retail's find_transit_cells never reads gfxobj_scale — added as a second residual on AP-156. R5: retail's slack constant carried into AP-158 and #333. A3: the per-call delegate allocation is back to a cached field, still derived from the single bounds resolver. A5: noted; b52967de's message cannot be amended. Gates: all 44 bin/obj deleted before every verdict-deciding build, each test run gated on a verified "Build succeeded" in the same invocation. Release build 0 errors / 21 pre-existing warnings. Complete suite 11,208 passed / 4 skipped / 0 failed — reconciles exactly with the e2b2d04c baseline; one test renamed, none added, removed or skipped. Nothing conflated with the known load-sensitive flakes #302 / #308 / #321. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 16:44:48 +02:00
Erik	b52967def3	fix(physics): AP-156 — flood the BSP sphere where the geometry is, not at the part origin ... The AP-152 retail review (docs/research/2026-08-06-ap152-review-retail.md) FAILED `4abd1b5e` and is right. `ShadowObjectRegistry.BuildFloodSpheres` took each physics-BSP part's ROOT BOUNDING SPHERE RADIUS (FlatCollisionAssetBuilder.cs:393 -> LiveEntityCollisionBuilder.cs:137) and centred it on the PART ORIGIN (ShadowShapeBuilder.cs:194), discarding the root sphere's own Origin. Re-measured independently against the installed client_portal.dat, reproducing the reviewer's numbers exactly: 376 of 973 physics-BSP parts have |origin| > radius/2, worst 20.762 m on a 27.708 m sphere (gfx 0x010036DD, Setup 0x0200129A). Over the 172 Setups AP-152 moved onto that path the emitted flood FAILED TO CONTAIN the object's own BSP sphere for 170 of them (73 CylSphere-bearing, 97 Sphere-bearing), worst shortfall 9.911 m on Setup 0x02000255 — whose one part's sphere sits 9.911 m above the part origin — and for 43 the post-AP-152 flood was strictly SMALLER than the pre-AP-152 one. Indoor flooding is 3-D (CellTransit.cs:601 routes every id & 0xFFFF >= 0x0100 candidate through FindTransitCellsSphere), so a tall prop or door slab was absent from EnvCells it physically occupies and therefore never a broadphase candidate there (TransitionTypes.cs:3763 iterates only entries already in the cell). That is the #98 / #168 class AP-152 exists to remove. Retail, re-disassembled from the PDB-paired binary (check_exe_pdb.py MATCH, CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32), every address resolved back through named-retail/symbols.json: CGfxObj::physics_sphere is [gfxobj+0x74] (physics_bsp is [+0x78], as CPartArray::CacheHasPhysicsBSP @0x00518110 reads at 0x00518127), and acclient pseudo-C 0x00534b5b assigns it BSPTREE::GetSphere(physics_bsp). BSPTREE::GetSphere @0x005397e0 8b01 mov eax,[ecx] ; BSPTREE::root_node 83c004 add eax,4 ; past BSPNODE::vfptr -> CSphere sphere So retail's per-part flood sphere IS the BSP root bounding sphere, ORIGIN INCLUDED (acclient.h: BSPNODE { vfptr; CSphere sphere; ... }, CSphere { Vector3 center; float radius; } -> radius at +0xc). CPhysicsObj::find_bbox_cell_list @0x00510fc0 adds the object's own cell and then walks the PART ARRAY: 0x00511012 call 0x518160 (CPartArray::calc_cross_cells_static), which dispatches [edx+0x7c] with (num_parts, parts, cellarray). Its EnvCell body, CEnvCell::find_transit_cells @0x0052cae0: 0x0052cb31 mov edx,[eax+0x20] ; CPhysicsPart::gfxobj (CGfxObj**) 0x0052cb36 mov esi,[ecx+0x74] ; physics_sphere (else +0x90 drawing) 0x0052cb4c add eax,0x30 ; CPhysicsPart::pos 0x0052cb5a call Position::localtolocal ; transform the sphere CENTRE 0x0052cb65 fadd [esi+0xc] ; only NOW the radius Retail transforms the centre through the part's own Position before it ever touches the radius. Carrying the radius alone is not an approximation of that; it is a different sphere. Changes: * `ShadowShape` gains `BoundsCenter` — the bounding sphere's centre in the shape's own local frame, scaled like LocalPosition and Radius. Zero for Cylinder/Sphere shapes, whose LocalPosition already IS their centre. * `ShadowShapeBuilder.FromSetup` gains a `physicsBspBounds` resolver that supplies radius AND centre from ONE call, replacing the placeholder radius plus a downstream substitution. `LiveEntityCollisionBuilder` now holds a single `Func<uint, FlatCollisionSphere?>` and derives its dispatch predicate from it, so the gate and the geometry cannot disagree and the radius cannot be taken while the origin is dropped. That split is what produced this bug; it no longer exists. * `FromLandblockBspParts` carries the centre too. A landblock-baked part array is the same CPartArray walk, so stair runs, fences and rock clusters had the identical defect. Both storage forms (flat BSP and the graph fallback) are covered. * `BuildFloodSpheres` places each sphere at partWorldPos + rotate(BoundsCenter, partWorldRot), composed exactly as the ShadowEntry rows are. * The 10-sphere clamp now applies to the CYLSPHERE branch only. Retail's clamp is inside CObjCell::find_cell_list @0x0052b9f0 (0x0052ba21 cmp eax,0xa / 0x0052ba28 mov ebp,0xa); the BSP walk has none and the sorting-sphere overload @0x0052b990 takes one sphere. 7 installed Setups carry more than 10 physics-BSP parts (max 49, Setup 0x02001A91) and their tail parts were dropped from the flood entirely. Without this the new containment assertion would have covered shapes production never floods from. Register. AP-155 was two divergences with different code paths, populations and gates under one id; it is NARROWED to its static-publication half and its flood half is split out as AP-156 WITH ITS DIRECTION CORRECTED. AP-155(b) recorded the approximation as over-inclusive — "floods MORE cells rather than fewer, the safe direction for membership" — and that false direction was the stated reason the residual was safe to defer. It was under-inclusive for 170 of 172. AP-156 records the correction, this fix, and the one genuine residual: acdream's sphere-vs-portal traversal where retail walks each part's sphere against the cell's own portal planes. AP-155(b)'s "acdream approximates retail's bounding BOX" was wrong too — find_bbox_cell_list forms no box. AP-157 filed for the review's F4: retail's third branch floods from ONE CPartArray::GetSortingSphere @0x00518b00 ([partArray+0x54]+0x70 = CSetup::sorting_sphere; 4,154 of 5,935 installed Setups carry a non-zero one) where acdream floods from every Sphere shape, and acdream's cylinder flood ignores CylHeight. Deliberately NOT bundled here: different branch, disjoint population, different live gate. Active AP rows 107 -> 109, literal count. Tests. Both flood tests the review named substituted a CONCENTRIC Radius = 14f at LocalPosition = Zero — the one configuration in which the defect cannot appear. Every fixture is now off-centre by default, and `FromSetup_CylSphereAndBspSetup_FloodsTheBspFootprint` drives the production `physicsBspBounds` seam instead of hand-substituting. Five new facts: the flood centres on BoundsCenter not the part origin; it rotates BoundsCenter by the part rotation; it caps cylspheres at ten but never the BSP parts; the landblock path carries the scaled centre in both storage forms; and an installed-DAT containment sweep asserting every emitted BSP flood sphere contains that part's real bounding sphere at entity scale 1.75, behind four external controls — 973 parts, 376 off-centre, 172 affected, and 170 would-fail-if-the-origin-were-discarded, the last of which fails if the population ever stops exercising the field. Nine sabotages, each reverted and re-verified: A drop BoundsCenter from the flood -> 3 Core B rotate by entity rot, not part rot -> 1 Core (the rotation fact only) C FromSetup discards the origin -> 1 Core + 2 App + 1 Content (the shipped defect, now caught in three projects) D drop entScale on BoundsCenter -> 2 App + 1 Content E landblock flat branch drops the centre -> 1 Core F landblock graph branch drops it -> 1 Core G drop partScale on the landblock centre -> 1 Core H re-apply the 10-cap to every branch -> 1 Core I remove the cylsphere cap -> 1 Core AP-152's own two sabotages re-run against this tree: the step-0 gate disabled still reddens exactly its five facts with Headless 89/89 green, and cylinder-first flooding still reddens exactly one. Clean Release build after deleting all 44 bin/obj: 0 errors, 21 pre-existing warnings. Complete suite 11,208 passed / 4 skipped / 0 failed, +5 on the 11,203 baseline at 4abd1b5e — Core 4264 -> 4268, Content 126 -> 127, App unchanged (one rename, not an addition). No new skips. NOT yet gated live. This moves shadow-cell membership for real objects, in both directions, and the connected session must look for both: props and doors that START blocking from a neighbouring cell (the 73 CylSphere+BSP Setups), AND ones that STOP blocking (the 99 Sphere+BSP Setups can shrink; 43 shrink below their pre-4abd1b5e size, which is the regression this fixes). Tall indoor props and door slabs — the ones whose sphere sits metres above the part origin — are where the change is largest. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 15:52:04 +02:00
Erik	bc4679cda5	fix(physics): delete the invented Setup-radius collision cylinder (AP-22) ... Retail synthesizes NO shape for a shapeless object, so the fix is deletion, not a corrected height formula. CPhysicsObj::FindObjCollisions @0x0050f050 dispatches exclusively -- BSP xor CylSphere xor Sphere xor nothing. The BSP branch leaves via an unconditional `jmp 0x50f2b0` at 0x0050f19d and cannot reach the primitive branches; a CylSphere-bearing object that survives its loop returns rather than falling through to the Sphere loop; and with zero cylspheres, zero spheres and no physics BSP, `0x0050f22f je 0x50f31b` branches straight to the epilogue, returning the OK_TS seeded at `0x0050f13b mov edi,1`. CPartArray::GetRadius (0x005180a0) and GetHeight (0x005180b0) are absent from the function's entire call set -- Setup.Radius/Height serve attack cones, cylinder_distance and MoveTo, never collision geometry. Disassembled directly from the PDB-paired binary (GUID 9e847e2f-777c-4bd9-886c-22256bb87f32) rather than read from the Binary Ninja text, whose ebp_1 aliasing in this function is visibly corrupt. THREE copies were deleted, not one. The AP-22 register row cited LiveEntityCollisionBuilder.cs and ShadowShapeBuilder.cs; the latter never reads Setup.Radius at all, and the row omitted both LandblockPhysicsPublisher.PublishStaticEntity and LandblockPhysicsContentBuilder.PublishStaticCollision -- the second being the only copy the headless host executes. Fixing just the cited site would have left headless statics on the invented footprint. The branch was unreachable dead code, not a live approximation. A sweep of all 5,935 Setups in the installed client_portal.dat -- validated by byte accounting (5,935/5,935 records consumed with an exact 20 + 48*numLights residual tail, zero unexplained bytes) and independently reproduced by the production FlatCollisionAssetBuilder.FlattenSetup path -- finds 0 Setups satisfying the guard: every Setup with Radius > 0.0001 carries at least one CylSphere or Sphere, and all 1,294 genuinely shapeless Setups have Radius exactly 0. Buckets: 678 cylsphere, 3,605 sphere-only, 358 BSP-only, 1,294 shapeless, 4,282 with Radius > 0.0001. Nothing loses collision because nothing gained it, so no visual gate is required. Tests, all sabotage-verified in both directions: - InstalledSetupCollisionReachabilityTests (new, Content) -- the negative claim plus five EXTERNAL positive controls, so a broken enumeration cannot satisfy it vacuously. Inverting the claim reddens it; emptying the enumeration fails on the controls at 0 != 5935 rather than passing. - ShapelessSetupWithRadius_ProducesNoRegistration (new, App) -- restoring the deleted block reddens exactly this fact and nothing else. - Build_PropagatesExactStateFlagsScaleAndFullSeedCell -- re-hosts the state / PWD-flag / seed-cell coverage that rode on the deleted fallback test, whose fixture (a Setup with a radius and no primitives) cannot exist in the DAT. Flipping a FromPwdBitfield bit reddens it; so does swapping SeedCellId for the landblock id. Also corrects ShadowShapeBuilder's retail-anchor comment, which claimed each part's find_obj_collisions tests "CylSpheres + GfxObj BSP". CPhysicsPart::find_obj_collisions @0x0050d8d0 tests ONLY the GfxObj physics BSP; CylSpheres are a Setup-level array reached via CPartArray::GetCylsphere. That comment was the written justification for the additive emission now filed as AP-152, so it is corrected here even though AP-152 is not fixed here. AP-22 retired with evidence; AP-152 filed (live path emits primitives AND BSP parts additively where retail is exclusive -- 172 of 5,935 Setups including BSP doors; deliberately not folded in, it needs its own visual gate). Issue #330 filed: the headless host registers no live-entity collision at all, a pre-existing gap this survey established and nothing tracked. Gates: Release build 0 errors / 0 warnings. Complete solution suite 11,195 passed / 4 skipped / 0 failed (baseline 11,193/4/0 at bcb66ccd; +1 App for the added fact, +1 Content for the reachability test; the replaced test is net zero). No new skips. Headless.Tests 89/89 exercises the site-3 copy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 08:27:26 +02:00
Erik	73cdb95c7b	fix(streaming): make a demoted landblock render-ready like a published one (#280 D-1) ... Both #280 review lenses returned FAIL on the same defect, and both were right. IsRenderNeighborhoodResident's widened outer arm requires IsRenderReady out to FarRadius, justified by "a Far-tier landblock registers with an empty mesh set and is therefore render-ready." That held only for a landblock that ARRIVED as Far. The second, equally first-class way to be Far tier is a Near->Far DEMOTE: DemoteLandblock -> EnqueueNearLayerRetirement -> LandblockRetirementStage.MeshReferences -> GpuWorldState.ReleaseLandblockMeshReferences -> LandblockSpawnAdapter.OnLandblockUnloaded => WantsLoaded = false while DetachNearLayer deliberately keeps the landblock loaded, terrain-mesh resident, terrain-collision resident and DRAWN. Nothing re-publishes an already-loaded landblock, so the demoted member satisfied NEITHER arm of the gate, permanently: wormhole tunnel plus centered "In Portal Space - Please Wait..." forever, no recovery short of relog. Reachable by ordinary play. Two consecutive recalls to the same landblock with walking in between makes ChangesStreamingCenter false, so there is no origin recenter and the region recentres through the ordinary demote diff. Also reachable via a mid-hold quality-preset drop -- ironically the exact scenario ReconcileDestinationReservationRadius was added to support. The pre-#280 radius-1 gate never touched that band, because nothing inside the Near ring can demote. FIX SHAPE. Make the two routes genuinely equivalent rather than teaching the predicate to tolerate the difference. ReleaseLandblockMeshReferences becomes "reconcile the registration to the post-retirement tier": after the release converges, if the landblock is still loaded AND still Far tier, re-assert the empty registration -- the identical OnLandblockLoaded(lb, empty) a PublicationKind.Far activation makes. It is empty by construction: DetachNearLayer retains only live server projections, which the adapter's atlas-tier filter skips. A full retirement is unaffected (DetachLandblock clears both _loaded and _tierByLandblock), and a throwing release still retries because the re-assert is only reached after the adapter converged. The alternative -- "|| (IsFarTier && IsLoaded)" at the gate -- was rejected: it fixes one caller while leaving IsRenderReady meaning two different things, which is precisely how this defect arose. After this change the predicate reads "drawable at its current tier" for every caller, with no knowledge of how the landblock got there. WHY THE TESTS MISSED IT, fixed here too: - Proof obligation P2 was discharged against RESIDENCY (the FarRadius+2 eviction threshold) rather than against IsRenderReady, the gate's actual atom. The contract now carries the correction and the restated obligation: no transition may REVOKE IsRenderReady from a landblock that stays inside FarRadius. - WorldRevealDerivedWindowIntegrationTests advertised itself as end-to-end against the real GpuWorldState but constructed it with no spawn adapter, so its IsRenderReady degenerated to IsLoaded via the "?? true". The single most load-bearing predicate in the change was stubbed out by a null in the test named after it -- the same shape as C5b's D3 and #276's three settler tests. Every fixture in that file now owns a real LandblockSpawnAdapter. - The P1 test's comment described its subject as "a Near-shaped completion the streaming window has since DEMOTED to Far". It is not; it is a fresh PublishAsFar, the case that does hold. Corrected, since a future reader would have taken it as demote coverage. Four new regression tests, all driving the real GpuWorldState + LandblockSpawnAdapter + LandblockPresentationPipeline through an actual demote, and all sabotage-verified in both directions (fail with the production change reverted, pass with it): NearToFarDemote_LeavesTheLandblockRenderReadyThroughTheRealPipeline NearToFarDemote_LeavesTheLandblockRenderReadyUnderBudgetedRetirement TieredWindow_StaysResidentAfterAnOuterRingDemote OutdoorReveal_SurvivesAnOuterRingDemoteDuringTheHold The budgeted variant exists because production composes LandblockRetirementCoordinator.CreateBudgeted, whose MeshReferences stage is a separate call site from the legacy pipeline's. SECONDARY, same commit: - R-1: ACDREAM_PROBE_REVEAL_RADIUS=0 was parser-accepted and Runtime-rejected -- it yields far = 0 for an outdoor destination, which fails invalid-readiness-shape on every acknowledgement, hanging the very A/B route the probe exists to measure. Parser floor raised to 1, with a 7-case table test. - R-2: the composite-warmup TRIGGER had silently moved onto the far window's critical path. Pre-#280 the gate and the composite domain were the same radius-1 square; #280 widened the gate without widening the domain, so every composite upload serialised behind the last outer-ring landblock for no readiness benefit. Warmup now starts once the NEAR sub-window is published -- trigger scope == domain scope, as before. The reveal gate is untouched: Evaluate still requires the full window AND composite readiness. - AP-150 filed: acdream's RetailWaitCueDelay = 5 s arming is NOT retail's trigger, and #280's commit message got this wrong on both clauses. Retail emits the notice unconditionally per tunnel rotation segment, in the else arm of the segment-expiry test at 0x004D6FCD; segment duration is RandDouble(0.6, 1.8) s, byte-decoded at 0x004D6FE6. The 5.0 constant at VA 0x007991B0 is CellManager::CheckPrefetchStatus's prefetch RETRY cadence and has nothing to do with the cue. acdream's own 0.6/1.8 segment constants already match retail exactly; only the arming is wrong. Adopting retail's unconditional emit is filed as #329 rather than folded in here -- it is a user-visible presentation change and wants the user's eyes. - AP-151 filed: the gate is materially STRICTER than retail on the mesh-build/GPU-upload axis. Retail's LScape::PreFetchCells blocks on DAT RESIDENCY only -- no geometry construction, no upload; that work is lazy at draw. acdream requires a DAT read, terrain mesh build, render-thread upload, spatial commit, collision admission and spawn-adapter activation per member of a 625-member window, metered at MaxCompletionsPerFrame. Nothing bounds the hold. This is the OPPOSITE asymmetry from AP-149; both are live at once, on different axes. - AD-2's amendment stated the false Far-tier readiness assumption verbatim; corrected, along with the same error in claude-memory/reference_two_tier_streaming.md, which now carries an explicit DO-NOT-RETRY on the special-case-the-predicate shape. - AP-115 scope-noted (it covers the cue's presentation, not its arming). - #326's SmartBox::set_mid_radius citation corrected: the entry is 0x00453180; 0x004531D0 is the mid-function re-arm branch. Blast radius: GpuWorldState, LandblockSpawnAdapter, WorldRevealReadinessBarrier and StreamingDiagnostics are all App-internal; AcDream.Headless and AcDream.Runtime reference none of them outside comments. Headless tests run green as part of the gate below, per C5b's lesson about surveys that skip the no-window host. Gates: Release build 0 errors, 18 pre-existing xUnit analyzer warnings. Complete suite "dotnet test AcDream.slnx -c Release -m:1" with ACDREAM_PAK_PATH set: 11,192 passed / 4 skipped / 0 failed, from a clean rebuild (a prior session's deleted probe file had been compiled into a stale test DLL). Baseline at fafc0b65 was 11,179 / 4 / 0; the +13 delta reconciles exactly to this commit's additions -- 3 readiness tests, 1 integration test, 7 parser table cases, 2 warmup-trigger tests. None of the known flakes #302/#308/#321 surfaced, and none is conflated with the finding above. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 07:27:28 +02:00
Erik	3aab05b0cc	fix(streaming): derive the portal reveal window from the live streaming radii (#280) ... The user watched far terrain visibly assemble after portal space exits. The reveal gate was NOT missing a hold — Slice E's hold mechanism is correct and already in place. The hold was measuring the wrong domain: it opened at a hardcoded 3x3 landblock neighbourhood (~192 m) while the visible world extends to the fog end (~2,189 m at the shipped High preset, inside a 2,304 m Far window). An 11.4:1 ratio. Retail's equivalent ratio is 1:1 BY CONSTRUCTION. `LScape` owns one `mid_width x mid_width` array of `CLandBlock*` (`LScape::SetMidRadius` @0x00504C00, `LScape::update_block` @0x005063A0), `mid_radius` is assigned directly from the user's `Render.LandscapeDrawDistance` preference (`SmartBox::SetRegion` @0x004531F0; values `Render_LandscapeDrawDistance_Values` @0x007CA988 = {3,5,8,11,15,25}, default 8 — both byte-verified against the PDB-paired 2013 binary), and that same square is simultaneously the prefetched set (`LScape::PreFetchCells` @0x00505660), the drawn set (`block_draw_list` over the same array), and the set the simulation blocks on (`CellManager::blocking_for_cells`). There is no retail configuration in which the client streams farther than it gates, because there is only one number. So the fix derives rather than duplicates. Four coupled parts, which is why this is one commit and not four — D1 without D2 hangs the client and D2 without D1 is dead code: D1 `WorldRevealReadinessBarrier` takes a live `Func<StreamingRevealWindow>` and stops being static: outdoor requires `FarRadius`, indoor still 0 (retail's `CEnvCell::PreFetchCells` @0x0052D1E0 arm). Read per evaluation, never captured — the radii are runtime mutable through Settings, and retail's answer to a mid-hold radius change is to reset, re-radius, and re-arm the blocking prefetch at the NEW value (`SmartBox::set_mid_radius` @0x00453180). `OutdoorNeighborhoodRadius` is deleted; there is no constant left to drift. D2 `StreamingController.IsRenderNeighborhoodResident` becomes tiered, because acdream's loaded landscape is: inside `NearRadius`, `IsNearTier && IsRenderReady`; out to `FarRadius`, `IsRenderReady` only. Without this the fix cannot work at all — nothing outside the Near ring is ever promoted, so any radius above `NearRadius` was unsatisfiable and would have held the reveal forever. Proof obligation P1 (a Far-tier landblock genuinely satisfies `IsRenderReady`) is now a test driven through the real `PublicationKind.Far` pipeline against a real `LandblockSpawnAdapter`, not an inference. D7 `RuntimeWorldTransitState.AcknowledgeDestinationReadiness` re-derived `indoor ? 0 : 1` and failed `invalid-readiness-shape` on any other value, so changing the radius alone would have looked like "the fix hangs the client". It is now a SHAPE invariant (`indoor => 0`, `outdoor => >= 1`). Runtime does not own the graphical host's streaming configuration and must not learn it; plumbing App radii into Runtime to preserve the strict equality is exactly the assert-a-mechanism-that-does- not-exist failure C5b was built to stop. Both non-graphical producers keep emitting their centre-ring token and stay legal, annotated in place. D6 `PhysicsEngine.IsNeighborhoodTerrainResident` rebuilt a full-map `HashSet` on every call, every frame of every hold. At radius 1 that was invisible; at radius 12 (625 ring members) it violates Slice I1's 0 B/resolve standard. Now an engine-owned scratch set, cleared in place; measured at 0 bytes over 1,000 warmed radius-12 queries. Also: the destination reservation opens at exactly the gate's radius and reopens on the same generation when the radius changes mid-hold (retail has one square for both, and no concept of prioritising an inner ring differently). Composite warmup deliberately stays `NearRadius`-scoped — the composite domain is entity-scoped and Far builds carry no entities, so widening it would walk the outer window to warm nothing. `ACDREAM_PROBE_REVEAL_RADIUS` is a measurement probe in a diagnostic owner (CLAUDE.md rule 5) so the connected route can be run A/B on one binary; it is NOT a user-facing prefetch knob, since a low setting would reintroduce the decoupling this slice exists to close. Register: AD-2 amended with the derived window, the two-tier split, and the four new retail anchors. AP-149 FILED for the residual this does not close — the outer ring accepts terrain-only publication where retail requires LandBlockInfo and every building EnvCell, so a distant building can still pop in at Far-ring distances. Do not let a later closeout claim parity. Docs: `ACDREAM_STREAM_RADIUS`'s CLAUDE.md description was wrong on every clause (the default is unset, not 2; it forces `NearRadius`; it is silently discarded by any Settings save) — corrected, since that is the file every session reads. `reference_two_tier_streaming.md` corrected in four ways, including "Far tier = terrain only": Far also publishes terrain COLLISION, which is precisely what makes this fix viable. #280's issue text had the right conclusion from a wrong premise (it names a view-distance setting acdream does not have) — corrected, and the missing Viewing Distance option filed separately as #326, with #327 (DDD progress readout) and #328 (hardcoded 5000 f far plane vs retail's byte-verified 4000) filed alongside. Expect LONGER holds and the "In Portal Space - Please Wait..." cue on recalls MORE often. That is convergence toward retail, not away from it: retail emits the byte-identical string for the whole duration of a blocked prefetch and polls at 5 s intervals. The failure condition is non-convergence, not duration. Gates: Release build 0 errors. Complete suite 11,178 passed / 4 skipped / 0 failed, against a re-measured 11,142 / 4 / 0 baseline at 9ee9c1a1 — +36, reconciled exactly as 36 new tests (App +23, Runtime +10, Core +3), zero deleted, zero newly skipped. Nine discriminating tests sabotage-verified in both directions. The connected/visual gate is batched into C5's matrix; its recipe, its three positive artifacts, and its required recall leg are written into the campaign plan. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 23:54:59 +02:00
Erik	ff100cf33f	fix(runtime): give the no-window host a post-merge canonical cell commit (D1, AD-60/AD-64, AP-146/#320) ... C5b (735f0a72) made the steady-state accepted-Position merge stop writing residency. That is retail-correct — HandleReceivedPosition @0x00453FD0 reads the wire objcell_id into a local and never assigns the object's cell — and it stays. What C5b did not account for is that its replacement writers both live in AcDream.App: the OnPosition prologue rebucket (AD-60's W2) and the post-routing wire-cell adopt (W3, AP-135). The two hosts run parallel, non-shared inbound routes. LiveEntitySessionController -> LiveEntityNetworkUpdateController.OnPosition is graphical-only; RuntimeLiveEntitySessionController.OnPositionUpdated is the no-window route and is constructed only at HeadlessSessionHost.cs:682. So AcDream.Headless had NO post-merge cell writer at all. Every remote's FullCellId was written at create/placement and then frozen for the session — and RuntimeEntityObjectViews .Snapshot projects exactly that field as RuntimeEntitySnapshot.CellId, i.e. every bot's entire world view. The local player lost one of AP-146's three refresh edges, which matters beyond cosmetics: RuntimeSetPositionState .IsAffectedCollisionResident reads FullCellId to pick which bodies a landblock retirement parks, so a bot running A->B without teleporting would have retired A while parking a body physically in B. The fix, in three parts: 1. RuntimeEntityObjectLifetime.CommitWireCellRebucket — a new Runtime owner for the committed VALUE, extracted verbatim from LiveEntityRuntime .RebucketLiveEntity. This is also the root-cause fix for the layering inversion the review found: AD-60 was documenting its own correctness by naming an App class the Runtime assembly cannot reference. Behaviour on the graphical side is unchanged — record.FullCellId is a proxy for record.Canonical.FullCellId, which is the record the callee reads, and the commit is still CommitRebucket. Verified load-bearing for BOTH hosts: sabotaging the preserve branch reddens the graphical LiveEntityRuntimeTests.CanonicalOnlyRebucket_DoesNotOverwriteAuthoritativeFullCell as well as the new headless assertion. 2. RuntimeLiveEntitySessionController.TryCommitAcceptedWireCell — the no-window W2, under the same reachability rules the graphical route applies: Rejected writes nothing (the shape the App authority gate produces by returning false); a bound-projectile packet writes nothing (routed by the graphical host through the canonical projectile placement owner, which returns before W2); an active initial-create residence writes nothing (RebucketLiveEntity's own early return — while the lease is live the SetPosition conductor is the sole cell authority); a local ForcePosition writes only when the accepted-Position drive declined it (NotApplicable), because a handled force is placement-receipt-authoritative. W2/W3 themselves are untouched. 3. On the committed value (the landblock-vs-cell trap). RebucketLiveEntity's preserve branch fires on a LANDBLOCK-shaped id — low 16 bits 0xFFFF — and exists for LocalPlayerProjectionController.Project, the per-frame local movement caller that emits exactly that shape. An inbound wire objcell_id is never landblock-shaped, so on the accepted-Position route the branch is not taken and the exact wire cell is committed. That is what W2 commits today and what this now commits; the no-window host has no per-frame caller at all. Ordering is matched, not improved on: the force drive submits its placement before the commit, so its first submit still reads the pre-commit FullCellId — AP-138's amended route-2 CurrentCellId measurement. Bookkeeping in this commit: - AD-60 corrected. Its surviving-channel enumeration presented "the local force path, the missile arm" as exhaustive; the entire no-window host belonged in it. 23aa62f2's W2/W3-redundancy measurement is preserved verbatim. - AP-146 and #320 amended the same way — their three-edge list was written from the graphical host and silently assumed both hosts shared it. The no-window host had two of three; it now has all three. - AD-64 filed: the reachability decision is now expressed once per host. The value is single-sourced; the gate set is not. - #324 filed: unifying the two session controllers is the genuinely correct fix and is campaign-sized (presentation recovery, hydration, the equipped-child renderer, and the remote/projectile routing arms only one host has). Not attempted here, per the fix brief. Gates. Release build 0 errors. Complete suite 11,141 passed / 4 skipped / 0 failed, against the 11,134 / 4 / 0 baseline at 23aa62f2 — net +7, exactly the 7 tests added. Eight sabotages verified, each red on at least one discriminating test and green when reverted: remote commit removed (2 Runtime + the end-to-end Headless test); local ordinary commit removed; local NotApplicable-force commit removed; force commit made unconditional; residence gate removed; missile gate removed; Rejected gate removed; preserve branch broken (red on both hosts). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 22:36:31 +02:00
Erik	23aa62f292	fix(review): close the C5b architecture-review findings (D2/D3/D4, L1-L5, S1) ... Follow-up to C5b (735f0a72). The retail-conformance review passed, so no production behaviour line moved: the flag truth table and the refreshPosition:false withhold are untouched. This is blast radius, test discrimination and documentation fidelity - plus two findings I could not confirm and am rebutting rather than complying with. D3 - THE PUBLISH-CONSERVATION TEST DID NOT DISCRIMINATE. The reviewer was right and it was the worst finding here: proof obligation 3's test passed identically with C5b reverted. Its only delta assertion FILTERED (Assert.Single(deltas, Rebucketed && parentGuid)), so the pre-C5b stream [Rebucketed] and the post-C5b stream [Updated, Rebucketed] both satisfied it, and childSpatialBefore+1 held in both worlds because whichever site did not move the cell propagated idempotently. It now asserts the complete ordered parent stream plus each element's CellId and Position.ObjCellId. Sabotage: restoring refreshPosition:acceptedPosition turns it red (it was green before), together with the withhold test and the new L5 test. That cardinality change was itself unfiled and is now AP-147: a cell-changing accepted Position publishes TWO entity deltas where it published one, and the intermediate Updated pairs the OLD CellId with the NEW wire Position - a torn pair that did not exist pre-C5b, since both halves used to move inside one publish. No production consumer reads a delta's paired fields, but a recorder/plugin/bot event log would capture it. The row states why suppressing the Updated is not available at that layer (the merge cannot know whether its caller reaches W2). D4 - THE PROJECTILE DOC COMMENT WAS FALSE AND ITS RETAIL ARGUMENT WAS INVERTED. SyncPresentationFromResolvedBody claimed record.FullCellId is "the WIRE cell ... stamped by the merge's RefreshDerivedState/SetFullCell, before classification ever runs" and argued from retail's store_position @0x00515CE2 that the destination cell is the right one. C5b falsified the premise; the missile arm also returns before W2, so nothing stamps the wire cell for a projectile at all. Rewritten. The honest conclusion, which the old text would have called wrong: on a stored outcome presentation now pairs the DESTINATION world position with the SOURCE cell. That is not a choice this method can make differently - StoreAcceptedDestinationPose writes only Position/Orientation, so record.FullCellId and body.CellPosition.ObjCellId now hold the same source cell and reading either yields the same value. The divergence is AP-138 item (1)'s store-writes-pose-but-not-cell residual, retiring via #309, not a field choice here. Projecting the wire cell instead would invent a residency the placement declined - the AP-1 shape C5b closed. L3/L4/L5 - PINNING GAPS, ALL THREE CONFIRMED AND CLOSED. L3: the matrix's oracle passed HasAnimations as a literal, so the merge's old.MotionTableId ?? old.Physics?.MotionTableId and RuntimeAcceptedPositionRouteRequests.Build's canonical-snapshot twin were textually identical and pinned by nothing. The oracle is now BUILT by the production constructor. L4: every fixture set both MotionTableId halves to the same value, so deleting either operand of the ?? was undetectable while the production comment said the mixed case is the real-world one. Six mixed rows added, including the explicit-zero row (a present-but-zero top half is not null, so ?? never reaches the physics half). L5: the retained Rebucketed ternary had zero coverage through TryApplyPosition - every restoreCancelledPark test called Forget directly. Now driven through the real merge, with the wire cell deliberately the SOURCE while the park's committed body cell is the DESTINATION, so the restored residency can only have come from the rollback. Sabotage (each red, each restored): merge ?? -> top half only, 1 red; -> physics half only, 2 red; Build's ?? -> physics half only, 2 red; ternary -> constant Updated, exactly the L5 test red. L1/L2 - THE MISSING TEST IS ADDED; THE DEFECT IS NOT THERE. The reviewer was right that C5b's "no fixture covers pickup at that layer" was inaccurate - LiveEntityNetworkOnPositionCollapseMatrixTests drives the real OnPosition at ~26 sites - and the end-to-end test is added: withdraw -> accepted Position -> IsSpatiallyProjected && FullCellId == wireCell, both guid classes. But ChildUnparentDisposition.Pending is NOT a live defect, because it is production-unreachable. The sole production _withdrawProjection binding (LivePresentationComposition.cs:599) is LiveEntityProjectionWithdrawalController.WithdrawExact, whose only Pending mint is inside its catch block and therefore always carries a non-null Failure - and AdvanceUnparentTransition rethrows at EquippedChildRenderController.cs:1307 BEFORE the return Pending at :1309. The named drop scenario does not reach it anyway (BeginDetachedRemoval has already emptied the capture list) and would be correct if it did: a previously-equipped child is LegacyImmediate, so the FullCellId != 0u gate at DatLiveEntityProjectionMaterializer.cs:767 is never consulted and re-projection uses the wire cell at LiveEntityRuntime.cs:824. Measured while building that test, and NOT what C5b assumed: W2 and W3 are REDUNDANT on the remote tail. Sabotaging W2 alone - adopting the committed cell instead of the wire cell, OR skipping the rebucket outright - leaves the whole file green, because W3's RemoteMotion.CellId write reads through to canonical FullCellId via CommitCanonicalCell, whose CellCommitted recovery re-installs the bucket. Only removing BOTH goes red, and then the new test is the only red in the file. So it is named for what it pins, and AD-60 is amended with the measurement: neither channel is individually load-bearing, so a future retirement of one is caught by nothing else. D2 - REBUTTED, WITH THE REAL GAP FILED INSTEAD. The reviewer's hypothesis was that TryApplyInitialCreateCompletionPresentation's staleness guard lost its ability to detect an intervening steady-state Position when C5b stopped the merge stamping the wire cell, and asked for a PositionAuthorityVersion term. I do not think that is right and did not add it. The receipt's facts are the canonical BODY's pose and cell at publish (PublishExecutorCompletion builds both from the record). Exactly two owners can move them: a Runtime SetPosition commit/withdrawal, every one of which calls AdvancePlacementCommit - the only caller family is RuntimeSetPositionState - and a rebucket, which moves FullCellId. Both are already covered by the two existing terms. An accepted steady-state Position is neither, and C5b did not make it one: the merge refreshes the snapshot and advances PositionAuthorityVersion but never wrote the body, and the App generic tail writes the RENDER entity. The wire-cell half stays covered because W2/W3 commit it in the same call; the paths that return before them leave the record at the last committed cell, which IS the receipt's own cell - correctly not a supersession. Adding the term would decline receipts whose facts are still true, on the entity's FIRST world-visible moment: the pose write and RebucketLiveEntityPresentationOnly would be skipped while TryPublishPlace still publishes, so a packet returning before the render write would leave the sidecar visible at its materialized pose in a wrong bucket. That is the handoff's own "removed the invariant failure while leaving the bug" shape. There IS one supersession neither term covers, and it predates C5b: RuntimeRemotePlacementDriveController.StoreAcceptedDestinationPose writes body.Position/Orientation on the far-snap Refused/Contention arm with no placement commit and no cell move. Filed as #323 with the FIFO-blocking argument for why a receipt can still be pending when it lands, an explicit "not established as reachable", and an explicit "do not fix it with PositionAuthorityVersion". The guard's comment now carries the whole argument instead of one sentence. S1 - DANGLING POINTER CLOSED. InboundPhysicsStateController.cs:610 still said the two-callers-one-rule debt was "tracked for the eventual cutover unification ... See docs/ISSUES.md", which pointed at nothing after C5b closed #275 without a successor. Filed #322, cited from both the comment and #275's closure, including why widening TryApplyPosition's signature to take a route would be the wrong unification. AP-138 amended: C5b staled its round-3 measurement that "both accepted-Position callers commit the accepted wire cell to record.FullCellId before submitting". Route 2 submits from TryExecuteAcceptedLocalPosition ahead of W2, so on a first submit PlacementTouchesPrefix's CurrentCellId arm now names the SOURCE landblock, not the destination. Confined to which prefix the quiescence pre-flight matches, which that row already established is not the correctness mechanism. GATES. Release build 0 errors. Complete suite 11,134 passed / 4 skipped / 0 failed, from the 11,125 / 4 baseline at ed806997: net +9, all new tests, no test deleted or weakened, no new skip. Runtime.Tests 1195 -> 1202 (+6 mixed-motion-table rows, +1 park-rollback fact); App.Tests 4132 -> 4134 (+2 guid rows). None of #302/#308/#321 appeared. Not connected-gated - nothing here changes runtime behaviour. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 22:08:46 +02:00
Erik	f8e55ba5e4	fix(physics): route local-player shadow presentation through SyncPose (#318, AP-145) ... RuntimePlacementPresentationSink.TryPublishPlace previously published the local player's collision-shadow pose with a direct LocalPlayerShadowState.Set call — a plain cache write that never touched PhysicsEngine.ShadowObjects. Because LocalPlayerShadowSynchronizer.SyncPose's own dedup check compares against that same cache, the direct write could pre-seed the cache with the destination pose and cause the next real SyncPose call to see "nothing changed" and skip its own ShadowObjects publish — leaving the real collision shadow at the pre-teleport position until an unrelated movement tick forced a real publish. Fix: TryPublishPlace now calls _localPlayerShadowSync.SyncPose(..., force: true), the same publisher ordinary per-tick movement uses, so Place always drives a real ShadowObjects write before the cache updates. TryPublishWithdrawal carried the exact mirror asymmetry (a bare LocalPlayerShadowState.Clear with no ShadowObjects.Suspend, leaving a live phantom shadow row at the park's source cell for the whole park window — the #184 shape) and is fixed in the same commit, same one-call shape: _localPlayerShadowSync.Suspend(entity). The sink no longer holds a direct LocalPlayerShadowState reference; both halves route exclusively through the one synchronizer, which owns the cache internally. The single LocalPlayerShadowSynchronizer instance is now constructed in LivePresentationComposition (before the sink) and threaded through LivePresentationResult to SessionPlayerComposition, which no longer builds its own — this guarantees the sink's Place/Withdraw edge and ordinary per-tick movement publish through the exact same publisher and cache rather than two independent instances that could drift out of sync with each other. TryPublishPlace's xmldoc now states the behavioural nuance directly: routing through SyncPose means Place inherits SyncPose's own admission guard (IsHidden, cellId == 0, not-current-visible-projection), which the old direct .Set() call never consulted. Under those conditions SyncPose now calls Suspend instead of publishing — correct and symmetric, but new behaviour worth flagging at the call site, not just in a test comment. RuntimePlacementShadowCompositionTests.cs (#318) proves four facts against the real ShadowObjects registry, not the cache: a bare Place publishes a real row at the destination cell with the source cell's row gone; a subsequent ordinary per-tick Sync is then a correct no-op; a Place for a registered non-local-player entity leaves its row at the source cell untouched and never touches the player's cache (route 7 P4 — the fix lives entirely inside the pre-existing player-only gate); and Withdraw suspends the real registry row, not just the cache, with the retained (suspendable) registration surviving for a later restore. All four were sabotage-verified in both directions. RuntimeForcePositionRenderCommitTests.cs (B2) drives a real end-to-end accepted ForcePosition through RuntimeEntityObjectLifetime.TryApplyPosition and RuntimeAcceptedPositionDriveController.TryExecuteAcceptedLocalPosition against a live HostFixture, asserting both the committed render position AND a cell change that deliberately crosses out of the spawn's outdoor grid cell, so the cell assertion is independently falsifiable rather than riding along with the position assertion. Retires AP-145 (this fix) in docs/architecture/retail-divergence-register.md. AP-1 and AD-1 are untouched by this commit — they retire separately in the deletion-sweep commit that follows. Evidence chain: docs/research/2026-08-05-c5a-contract.md (the governing C5a slice contract), docs/research/2026-08-05-c5a-architecture-review.md (round 1, FAIL — three MAJORs: vacuous route-7 P4 test, unfixed Withdraw-side mirror asymmetry, non-driving B2 test), docs/research/2026-08-05-c5a-architecture-review-round2.md (round 2, PASS with two MINORs — an unfalsifiable B2 cell assertion and the undocumented SyncPose guard nuance, both fixed here). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 14:09:11 +02:00
Erik	392c1e22c1	fix(physics): bind a parented child to the parent's live incarnation (#319) ... A player-parented child never received a canonical cell. Its FullCellId stayed 0 for its whole attached lifetime, so it could not follow the player across a boundary. Scope was wider than the local player: every REMOTE player's equipment too. ROOT CAUSE. EquippedChildRenderController hardcoded ParentInstanceSequence: 0 for a parented CreateObject. Correct for creatures and statics, which really are sequence 0; wrong for players, whose ObjectInstance is Character.TotalLogins (ACE Player_Networking.cs:37). The relation filed under (playerGuid, 0) while the record carried TotalLogins, so both route-7 write sites — D1's attach re-cell and D2's propagation lookup — keyed on an incarnation that never matched. TryCommitParent did not validate the sequence, so the attach succeeded and printed normally. Silent. A ROUTE 7 REGRESSION (cd3129e9) that un-masked a latent bug: the TickChild call route 7 deleted was keyed on the child guid alone and was structurally immune to a wrong parent key. THE FIX IS TO STOP TREATING PLAYERS DIFFERENTLY, not to special-case them. Retail's attach path is guid-only end to end — PhysicsDesc::get_parent_id @0x00558a18 -> CObjectMaint::GetObjectA @0x00558a2d -> set_parent @0x00558a3e, with SetChildren @0x00509370 hash-walking by guid — and neither set_parent overload (@0x00515A90, @0x00515B50) nor enter_cell @0x00510ED0 contains any player test or instance-sequence read. Our player/non-player split was purely an artifact of keying relations by (guid, incarnation) against a wire message that carries no parent incarnation. Late-binding to whoever currently holds the guid is retail's own semantics. Fixed at BOTH producers: OnSpawn and OnCreateParentAccepted, the second carrying the byte-identical defect and not named in the contract's scope line. THE INVARIANT IS EQUALITY, NOT FRESHNESS. The contract rejected both framings I offered: every one of the 45 FullCellId liveness predicates excludes a committed child on a NON-cell clause first, so the child inherits only the parent record's existing staleness, which is already present today with no symptom. The key fix alone restores child-equals-parent for every parent class. TWO SITES GATED, inert only because the cell was zero and would have woken wrongly: the hydration candidate loop (a nonzero-cell child would take the legacy RebucketLiveEntity -> CommitRebucket, a second canonical writer — route 7's exact defect class) and RestoreShadow (would install a broadphase row for the weapon, the #184 shape, contradicting route 7's P4). Retail anchor: update_object's parent != 0 early-out @0x00515D40 — children are never independently re-placed. THREE MAJORS WERE FIXED BY DELETION. The first pass added a deferral queue for an unaddressable parent, carrying a missing child-freshness gate (A2), a sentinel-0 collision with the generation filters (A3), and unbounded accumulation (A5). Both reviewers then proved the deferred branch unreachable for BOTH producers — RegisterEntityCore defers the entire CreateObject one layer above, reading the same ?? chain, and CreateParentUpdate is produced only inside AcceptCreateCore, after that gate passes. The machinery was deleted rather than repaired, and the diff SHRANK to 76 added / 13 removed from 91/24 while gaining the A1 fix. Retail confirmed the deletion does not diverge: acdream's real port of retail's per-guid replay (QueueBlobForObject) is a different, untouched layer, and the deleted queue was a third redundant one downstream of it. THE GUARD MUST NOT TEAR WHAT IT PROTECTS. The first pass threw InvalidOperationException AFTER the canonical half had committed, so the one time it fired it left the child parented with no committed relation and a staged one blocking Resolve — a torn transaction, the exact outcome the contract pinned against. Now a pure CanCommitIncarnation precondition checked BEFORE the commit at both sites, with a logged refusal instead of a throw. Route 3's N3 principle (do not make a transient fatal on a host that must survive 30 sessions x 2 hours) reinforces it, but the tearing argument stands alone. TEST QUALITY, the recurring lesson in its most refined form. The A1 test initially passed sabotage FOR THE WRONG REASON: a mismatched ChildPositionSequence meant TryCommitParent's own gate refused in either ordering, so the three assertions carrying A1's meaning passed both ways and only an incidental staging assertion failed. It failed on stranding, not tearing. Corrected, the sabotage now names line 925 — Assert.Null(snapshot.ParentGuid), with the parent's guid in it — proving the canonical mutation happened before the catch. "Fails under sabotage" is necessary, not sufficient; WHICH assertion fails is the real question. The dual parent-class matrix (player 0x5… incarnation > 1 vs creature 0x8… incarnation 0, identical outcomes, sabotage-verified in both directions) is the structural fix for how this survived a full dual review and two connected sessions: every prior test and both captured gate logs used sequence-0 parents. Register: AP-142 clause (f); AP-132 amended to distinguish the two producers; new row AP-146 for the local player's coarse canonical cell (retail writes it per tick at SetPositionInternal @0x00515330 — which, per the retail review, ALSO walks this->children writing each child's objcell_id @0x005153AE-@0x005153D8, so retail's per-tick child propagation lives in the same function). That divergence had no row at all, a standing rule-1 violation now corrected. Follow-up #320 filed for making the player's cell track ordinary movement — deliberately excluded here: it touches the landblock-preserve contract, the Rebucketed cadence, route-2/4b-3 classification inputs AP-136/AP-138 spent four review rounds pinning, and the portal-space frozen-source-cell race. Two dual review rounds; 6 architecture MAJORs and 2 retail MAJORs closed. Diagnostic refusals are latched per child guid and the latch clears on Clear()/RemoveChild, so a recycled guid's next incarnation still logs rather than being silently suppressed. Complete Release suite MEASURED at 11,112 passed / 4 skipped / 0 failed (baseline 11,090 at 52175aa1, +22). Neither known flake fired. STILL OWED: the connected gate, with the CORRECTED positive criterion — assert the equipped child's FullCellId EQUALS the parent's after a crossing (a zero is a failure, not a silence), run with BOTH a player and a creature parent, plus the new step carrying an armed creature across a landblock unload/reload. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 11:56:31 +02:00
Erik	e0f96a55bf	fix(physics): C4 route 3 — portal placement authority (local player) ... Removes a duplicate placement authority for local-player portal arrival. Portalling worked before this change and works after it — this is not a bug fix, EXCEPT that it found and fixed one dead-code production bug. THE PRODUCTION BUG: TryExecuteCanonicalPortalPlacement re-read the accepted destination at Place time, but TryBeginPortalReveal already consumes that slot at Aim time — so the arm was 100% dead code and every real portal Place refused with host-token-unavailable. Found only because we refused to accept 7 skipped tests instead of chasing the count to zero. RETAIL IS THE GENERIC PATH FOR THE THIRD ROUTE RUNNING: SmartBox::TeleportPlayer @0x00453910 = SetPositionSimple(dest, 1) with flags 0x1012, followed by PlayerPositionUpdated. BOTH INVERSIONS, WITH THEIR ANCHORS: unlike route 2, the leash IS armed here (ConstrainTo @0x0045418A) and velocity is zeroed (set_velocity @0x004541B4); unlike route 4b-3, the local teleport_hook runs AFTER placement (@0x004538AE). THE THREE-ROUND DEFECT CHAIN, HONESTLY: - Round 1 released the player at the pre-teleport position while the anim stream marched on — the contract wrongly assumed Place re-fires (process rule 1's third occurrence this campaign). - Round 2's fix inferred commit from a global PendingCount, which three non-committing paths also clear — making the SAME bug complete cleanly and silently. Strictly worse than round 1: round 1 at least tripped portal-complete-before-materialized. - Round 3 latches the commit where it actually happens (ReconcileAndAcknowledgePortal), keyed on reveal generation and teleport sequence, via TryConsumePortalCommit. Two of the three required regression tests landed and are sabotage-verified on both hosts (ParkedPlace_ForgottenByOrdinaryMergeDoesNotLatchAsCommitted / HeadlessPortalPrepareDestinationForgottenByOrdinaryMergeDoesNotLatchAsCommitted). The third (force-arm-takes-the-slot) was judged unnecessary on review: with the inference gone, PendingCount is only a "don't ask yet" guard at both gates, so a force operation occupying or vacating the slot no longer changes an input the commit decision reads — the case collapses into what the landed test already discriminates. THE B2/P3 RESOLUTION: both round-2 reviews were right about different branches of the same synchronous call. RuntimePlacementProjectionSubscription .OnPlacement acknowledges the FIFO head only when TryApply returns true; a Place whose portal authority went stale (transit ended/superseded while parked) used to return false, wedging every later entity's placement receipt behind it forever. Both sinks (RuntimePlacementPresentationSink, HeadlessRuntimePlacementProjectionSink) now acknowledge-and-ignore a stale-authority Place instead of refusing it. The regression test (RuntimePlacementPresentationSinkTests .PortalPlace_StaleTransitHostOrSequenceIsAcknowledgedAndIgnored) had been asserting the old, wrong `false` behaviour; it now asserts and sabotage-verifies the fix. Also lands: AP-144 (register discipline — the portal movement-event send reuses the stricter UsePositionFromServer gate where retail's SendMovementEvent is the looser autonomy_level != 0 test, diverging only at level 1, currently unreachable), AP-145 + issue #318 (the local-player collision-shadow presentation write bypasses its own publisher's ShadowObjects write via a direct cache .Set(), self-healing only once dedup diverges — filed, not fixed, pending a composition test), AD-42 deleted (its last citation retired by the canonical portal arm), AD-2 updated (the wait-cue's trigger predicate now covers a second cause), and two documentation corrections: the enter_world misattribution (both call sites are in SmartBox::HandleCreateObject, only one in the player branch — portal arrival is TeleportPlayer, not enter_world) and the stale "local player never reaches this path" comment on the generic-remote-render-pose write. Suite: 11,090 passed / 4 skipped / 0 failed. No new skips, nothing weakened. STILL OWED: the connected two-client gate, with ACDREAM_PROBE_LOCAL_TELEPORT=1, scored only if [local-tp] lines actually appear in the capture — and explicitly NOT scored as covering issue #318 (no composition test yet asserts PhysicsEngine.ShadowObjects directly). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 03:57:37 +02:00
Erik	cd3129e9d6	fix(physics): C4 route 7 — child cell propagation moves from a render tick into Runtime ... Retail re-cells children when their parent crosses a cell, recursively, to unbounded depth. acdream did it from a RENDER tick, so headless parented children were cell-less forever and the canonical cell had two writers. This slice makes Runtime the sole authority and demotes App's tick to presentation-only. Contract: docs/research/2026-08-04-c4-route-7-contract.md; the research that unblocked it is docs/research/2026-08-04-retail-parent-cell-propagation.md (ca96ea5e). Retail: SetPositionInternal @0x00515330 branches on `this->cell == curr_cell` @0x0051536d; the changed branch reaches change_cell @0x00513390, whose delegates leave_cell @0x00510f50 and enter_cell @0x00510ed0 self-recurse over children and write the FULL identity (add_object @0x00510ee2, objcell_id @0x00510f1e, part-array cell id @0x00510f2b, cell pointer @0x00510f35). change_cell itself has no child loop. THE TRAP, recorded because it nearly shipped: the depth-1 loop @0x0051539c-0x005153d8 is the SAME-CELL fast path (objcell_id and part-array id only, deliberately not the cell pointer), NOT the propagation. An implementer who finds it first concludes "depth-1, id-only" and strands every equipped item at a landblock boundary — the #184 class. The clincher against that reading: update_object @0x00515d10 early-returns on `parent != 0` @0x00515d40, so a child never runs its own physics tick and parent propagation is the ONLY mechanism maintaining its cell. Route 7 performs NO placement (DoPickupEvent @0x00452240 = unset_parent + leave_world; DoParentEvent @0x00452290 = set_parent + SetPlacementFrame), so it arms ConstrainTo nowhere — the leash rule INVERTS relative to routes 2/4/5, and both reviewers confirmed nothing arms. Propagation is an ITERATIVE WORKLIST, not recursion. The first implementation recursed with a depth-64 cap; both reviews independently found the cap left a truncated tail at a stale NON-ZERO cell — permanently unrecoverable, logged only under a probe flag, and on the withdraw path exactly the #184 shape AP-142 clause (a) exists to reject. Shipping a fresh #184 instance inside the slice that fixes stranded children was not acceptable, so the cap was removed rather than tuned. The worklist retires the cap, the constant, its register clause, and the failure mode together. Termination: every record on the stack is already at the target pair, so nothing can be pushed twice and a hostile A->B->A cycle collapses without a visited set. The child write deliberately bypasses the public RuntimeEntityDirectory .SetFullCell and calls the record method directly. This is LOAD-BEARING: the public method re-enters PropagateFullCellToChildren, which opens with _propagationWorklist.Clear() — routing children through it mid-drain would wipe the shared stack and silently drop every unprocessed sibling. Any future side effect added to the public SetFullCell must be mirrored by hand at that call site. Deliberate divergence, recorded not disguised: retail's removal path leaves children with a null cell pointer but a STALE nonzero objcell_id @0x005133c1. acdream does not reproduce it, because FullCellId != 0 is the liveness predicate at 45+ sites — faithful porting would mark dead children live. AP-142 records this; clause (d) records that acdream cannot gate propagation on HasPartArray the way enter_cell gates on part_array @0x00510ed8, because the flag's only writers are graphical and headless never sets it — the reason is Slice J LAYERING, not a semantic difference (retail's part_array is itself a mesh-construction product, single assignment site makeAnimObject @0x0050e930 -> CPartArray::CreateSetup @0x0050e93e). D7 adopts retail's unset_parent-before-leave_world order @0x0045227f -> @0x00452286, applied to BOTH pickup paths including the dormant executor replay. Its inertness was verified by reverting it and finding all 12 propagation tests still green — reported honestly rather than papered over with a manufactured test, and independently confirmed by both reviewers. ClassifyLeaveWorld and its request/cause types are DELETED: retail has no classification here, and method-per-cause IS the retail dispatch shape. Wiring it would have forced a vacuous teleport-sequence predicate with the #307 shape. Two review rounds plus a coordinator-required third pass; 5 MAJORs. One was a handoff failure worth recording: enter_cell's part_array guard was correctly identified as load-bearing by the research, dropped by the contract when it enumerated the writes, and inherited as an omission by the code — a right finding that evaporated across two handoffs with nobody re-reading the source. Another was a test that survived deleting the entire behaviour it claimed to pin, because its assertion read a field written unconditionally one line earlier. NoProjection is structurally unreachable from TickChild (TryResolveExactAttachment performs a strictly stronger form of the same guard one call earlier). Kept as a fail-safe, unit-tested directly, and documented in two places rather than wrapped in a fabricated end-to-end test. Headless regression test — the direct gate for this defect, which FAILED before this work because no code path existed: RuntimeLiveEntitySessionControllerTests .DirectSink_D5_StandaloneParentEventCommitsChildToParentsExactCell. Probe: ACDREAM_PROBE_CHILD_CELL=1 emits [child-cell] lines at all four write sites (attach / headless-attach / propagate / withdraw / delete). TEMPORARY. Complete Release suite MEASURED at 11,079 passed / 4 skipped / 0 failed (baseline 11,063 at cff52c44, +16). An allocation flake appeared once under load and was proven NOT this slice by reachability — RuntimeCollisionReportingState contains zero SetFullCell and zero ParentAttachments references. STILL OWED: the two-client connected gate (equip/unequip, carry across landblock boundaries, pickup, loot, reconnect) with ACDREAM_PROBE_CHILD_CELL=1, and a session counts only if [child-cell] cause=propagate lines appear. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 23:53:05 +02:00
Erik	cff52c44f4	docs(physics): correct stale set_velocity claim in the 4a remote velocity comment ... LiveEntityNetworkUpdateController.cs's TryCommitAuthoritativeVelocity call site carried a comment claiming "MoveOrTeleport installs that exact vector with set_velocity". The C4 route 5 byte-decode of CPhysicsObj::MoveOrTeleport @0x00516330-0x00516438 (the immediately preceding commit) shows this is false: the function never reads its velocity argument's stack slot in any branch, and UnpackPositionEvent performs no set_velocity either. The only set_velocity in the whole accepted-Position chain zeroes the LOCAL player @0x004541B4, a different call site entirely. This commit only corrects the comment. The 4a call itself is left unchanged in production, deliberately out of C4 route 5's scope — the route governs RuntimeSetPositionOperationKind placement dispatch, not the pre-existing remote velocity commit. #317 (docs/ISSUES.md, filed in the previous commit) tracks the follow-up: audit the whole accepted-Position velocity chain and either find the correct retail source or remove the call with a divergence-register row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 21:04:06 +02:00
Erik	36255af0f6	fix(physics): C4 route 5 — projectile authoritative placement (#276 partial) ... Ports retail's missile Position handling into the canonical Runtime placement owner instead of the deleted ApplyAuthoritativePosition short-circuit. The Create/residence-window halves of the projectile pipeline (RuntimeProjectile binding, TryBind's adopted-body branch, the collision/shadow registration) were already canonical from prior slices; this closes the remaining gap — how an ACCEPTED Position for an in-flight missile is classified, placed, and presented. Byte-decode (Step 1 hard gate, before any code was written): CPhysicsObj::MoveOrTeleport @0x00516330-0x00516438 disassembled from the PDB-paired binary (Capstone, x86 32-bit thiscall). `ret 0x10` establishes four stack args; [esp+0x7c] (arg5, the velocity pointer) is never referenced in any of the three branches (teleport/near/far). The retail reviewer independently reproduced this by searching the whole function body for the `24 7c` mod/rm+disp8 encoding a `[esp+0x7c]` read would require and found zero occurrences. This retired a fabricated `?? Vector3.Zero` fallback in the deleted method — retail's PositionPack::UnPack initializes an absent velocity to zero and MoveOrTeleport never installs it; the projectile's Vector channel (RuntimeProjectilePhysicsUpdater.ApplyAuthoritativeVector) remains the sole velocity authority for a missile. D-P5 in the contract; the Runtime seam commits no velocity from the Position packet at all. The unbound-missile fix: RuntimeEntityObjectLifetime's ClassifyRemoteAcceptedPosition now derives ProjectileAuthoritative from a CONJUNCTIVE predicate — the Missile bit AND a bound RuntimeProjectile whose Body is the canonical PhysicsBody — never the bit alone. Retail places every non-player CPhysicsObj unconditionally (there is no missile-specific placement gate in MoveOrTeleport or its callers), so an unbindable or not-yet-bound missile taking the ordinary remote tail is retail-faithful, not a fallback: the earlier bit-only discriminator would have silently frozen it instead. AP-141 records this as a deliberate, recorded divergence, not fidelity. Retail mechanically WOULD arm a missile's ConstrainTo leash on any nonzero MoveOrTeleport return: HandleReceivedPosition @0x00453FD0's only kind test is player-vs-not, ConstrainTo @0x00454272 has no kind test of its own, and CPhysicsObj::ConstrainTo @0x00510520 creates a PositionManager on demand via MakePositionManager @0x00510523 if one doesn't exist. acdream deliberately does not construct that EntityPhysicsHost/ PositionManager/InterpolationManager chain for a ballistic body — the route-5b split the C4 route 5 contract rejected — so a live missile never shows an armed leash and never catches up via the near/ UnroutedCatchUp policy. This divergence is safe specifically because ACE never sends UpdatePosition for a missile (references/ACE/Source/ACE.Server/WorldObjects/WorldObject_Tick.cs: 333-334, SendUpdatePosition() commented out inside the PhysicsState.Missile branch at :265) — every half of this row is deterministic-test-gated only, never exercised against a real server. AP-141 also records the surviving ConstrainTo re-anchor divergence under clause (b): for the adopted-body case (TryBind's shared-body branch — an ordinary remote whose Missile bit is set by a later State packet, so it still carries a live RemoteMotion), acdream now ports retail's teleport-branch and far-branch StopInterpolating action (Interp.Clear()), but never re-arms or re-anchors the inherited ConstrainTo leash the way retail's HandleReceivedPosition @0x00454254/@0x00454272 does on every nonzero return. The risk column's earlier wording — that a stale leash "would drag the body toward a stale anchor" — was wrong and is retracted in this same commit: ConstraintManager.ConstraintPos is write-only in both retail and the port (never read by AdjustOffset), and ConstraintManager::adjust_offset @0x00556180 only tapers or zeroes an already-composed per-tick offset while InContact — a leash brakes motion the interp/sticky chain already produced, it cannot pull anything toward the anchor. The real residual is one tick of un-reset brake accumulator, contact-gated, and it cannot move an airborne far-snapped missile at all (the clamp branch does not run while airborne). NO CONNECTED GATE EXISTS for this route, by design: ACE never sends a missile UpdatePosition (see above), so retail's own server never exercises this code path in play. Every proof obligation here is test-gated only — Runtime and App-level fixtures constructing the packet directly — never a live client/server capture. Three review rounds closed 8 MAJOR findings before this landed: round 1 (A1 App discarded the seam's status; A2/R1 silent swallow on an unbound missile; A3/R2 the adopted-body teleport_hook never wired; A4/A5 zero Runtime/App test coverage); round 2 (a ParentCellId regression introduced by round 1's own R6 finding, which the retail reviewer retracted the following round as factually wrong — the fix here is the REVERT to record.FullCellId, not the relocation round 1 shipped; B2 the far-branch StopInterpolating skip never extended to the adopted-body case; residual App/Runtime store- path coverage; a per-packet closure contradicting the file's own #315 cached-delegate pattern). Round 3 closed on coverage alone (no defect): the Advance() retry arm's projectile branch — added at round 2, semantically reordered at round 2's B5 fix (skip prediction invalidation on a re-parked Contention, since it writes nothing) — had never been executed by any test; two new tests drive it directly and are sabotage-verified against both the reordering and the retry-arm's own SyncProjectilePresentation call site. The one recorded defect this campaign produced (the ParentCellId regression) was caused by complying with a review finding that its own author later retracted — the standing lesson recorded for future rounds is that review findings are evidence to re-verify against the code, not commands to obey unconditionally. Complete Release suite: 11,063 passed / 4 skipped / 0 failed (baseline 11,036 at 30d3d114, +27 new tests across this campaign). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 21:03:41 +02:00
Erik	aaf0811f18	fix(physics): close #315 — cache the remote-arm callbacks instead of allocating per packet ... The OnPosition collapse (previous commit) converged RunRemoteArmTail's three duplicated call sites into one, which is what makes caching worthwhile: one cached pair of delegates now serves every remote guid instead of a fresh closure allocated on every accepted remote Position (5-10 Hz per remote), regardless of whether the packet was a teleport. RunRemoteArmTail's signature changes from a caller-constructed `Func<bool> isCurrentPositionOwner` closure to two plain value parameters (`ulong positionAuthorityVersion`, `WorldEntity? expectedEntity`). It stamps five per-packet scratch fields (`_remoteArmCanonical`, `_remoteArmMotion`, `_remoteArmPositionRecord`, `_remoteArmPositionAuthorityVersion`, `_remoteArmExpectedEntity`) from its own parameters, then passes the two CACHED delegates into ApplyRemoteContactRouting. Observably identical: the currency check reads the exact same positionRecord/positionAuthorityVersion/expectedEntity triple either way. Deviation from a bare cached-Func<bool>-field design, and why: UpdateFrameOrchestratorTests.ProductionFrameAdaptersRetainTypedOwnersWithoutWindowCallbacks asserts every typed production owner (LiveEntityNetworkUpdateController included) carries zero Delegate-typed fields — the GameWindow decomposition campaign's guard against a callback silently smuggling a window reference back onto one of these owners. Neither cached delegate here touches a window (both are bound to this controller alone), but the rule is written as a blanket field-type check, not a window-specific one. The two delegates are wrapped in a small nested RemoteArmCallbacks type instead of being bare fields, which satisfies the guard and keeps the cache a single named, auditable unit rather than working around the test. RunRemoteTeleportHook's own allocation (the six-action RemoteTeleportHookActions bundle) is unaffected — it stays teleport-path-only, already judged acceptable to defer by the C4 route 4b-3 round-2 architecture review's B4 finding. dotnet build AcDream.slnx -c Release: 0 errors. Focused suites green at this commit: AcDream.App.Tests 4104/4107 (3 pre-existing skips), AcDream.Runtime.Tests 1125/1125. Closes #315. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 18:11:36 +02:00
Erik	edc911b042	refactor(physics): collapse OnPosition's dual player/NPC remote tail into one ... C4 route 4b-3 collapse (docs/research/2026-08-04-onposition-collapse-contract.md). Behaviour-preserving: the ~640-line duplicated player-guid and NPC-guid copies of the remote routing tail in LiveEntityNetworkUpdateController.OnPosition become one guid-blind tail, reached by every remote guid through the single ApplyRemoteContactRouting/RunRemoteArmTail seam. Two guid-conditionals survive, both named and justified: - Row 8 (TS-44 sticky suppression, creature-only): retail's sticky is independent of this acdream-only steady-state gate; the register row already describes it as NPC-only and this collapse does not widen it. - The AirborneSnap arm's interp-clear + shadow-publish (rows 2a/2b, player-only preserve): unifying either way would be an unauthorized behaviour change. #316 (shadow publish) is a real, unmeasured pre-existing defect, deliberately preserved not fixed. The interp-clear's equivalence could not be proven for the steep-non-walkable-landing edge case (AdjustOffset's CONTACT-keyed gate vs. AP-139's WALKABLE-keyed per-tick clear) — preserved per contract stop condition 2 rather than shipped on an incomplete proof. Category-(c) resolutions (contract §2.1-2.5), each with its evidence: - Row 2a (interp clear): PRESERVED — AdjustOffset's `if (!inContact) return` proves inertness on flat landings, but not on the steep-contact edge case. - Row 2b (shadow publish / #316): PRESERVED — no design note ever sanctioned the player-guid skip; the file's own #184 Slice 2b comments contradict it. - Row 2c (EnsureRemoteMotionBindings): UNIFIED — the method is idempotent (`if (rm.Host is not null) return rm.Sink;`), so "always ensure" is safe. - Row 3 (wire-cell adopt ordering): UNIFIED — RebucketLiveEntity already commits the wire cell before either guid branch runs, so the deleted player-guid pre-write was a proven no-op. - Row 4 (LastServerPos/Time sample timing): UNIFIED — on a genuine first UP, InterpolationManager.Enqueue's already-close branch and the Snapped branch both converge on the same body pose/orientation for a zero-distance target. - Row 12 (wall-clock capture): UNIFIED — one shared `nowSec`, a microsecond-scale skew in acdream-only bookkeeping/diagnostics. Sabotage check (contract §5, performed and reverted, not committed): deleting the one remaining TryArmConstraintAfterOperation call failed 10/16 dual-guid matrix tests, spanning BOTH guid halves of every arming-dependent scenario (teleport, landing, near, far, sticky) — proof the matrix discriminates a defect regardless of which guid range exercises it, closing the class of bug that let 4b-3's A1/A2/R3 findings survive review when only one copy's tests were green. New tests/AcDream.App.Tests/Physics/LiveEntityNetworkOnPositionCollapseMatrixTests.cs drives 8 scenarios x 2 guid ranges (0x50xxxxxx player, 0x8xxxxxxx creature) through the complete production OnPosition entry point. Doc comments on ApplyRemoteContactRouting, RunRemoteArmTail, ApplyWireAirborneLeftoverBookkeeping, TryAdoptWireCellAfterRouting, and the AirborneNoOperation throw guard updated to describe the collapsed one-path world (the "two callers stay one decision" claim was true before this commit and false after — fixed in the same commit that makes it false). One branch-routing source-text pin (LiveEntityNetworkBranchRoutingTests.cs) updated to follow the AP-140 CONTACT gate to its new address inside ApplyRemoteContactRouting. #316 stays OPEN, deliberately not fixed here — see its updated ISSUES.md entry. dotnet build AcDream.slnx -c Release: 0 errors. Verified independently bisectable at this exact commit: AcDream.App.Tests 4104/4107 (3 pre-existing skips), AcDream.Runtime.Tests 1125/1125. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 18:07:54 +02:00
Erik	daef7c9835	fix(inventory): reset a split result's movement timestamps so recovery cannot throw (#314) ... Found by C4 route 6's integration tests (1b484937) and split out of that zero-production closure per the standing split-on-discovery rule. PendingSplitToWorldProjection.BuildSpawn zeroes the top-level MovementSequence/ServerControlSequence, but its Physics.Timestamps `with` block overrode only Position/Teleport/ForcePosition/Instance — leaving Timestamps.Movement and .ServerControlledMove at the SOURCE item's values. RuntimeEntityObjectLifetime.HasConsistentCreateIdentityAndParent requires the PhysicsDesc timestamps and their flattened projections to agree, so the synthetic spawn failed the predicate and TryRecoverUnknownPosition threw `CreateObject 0x… has inconsistent instance or parent projections` instead of completing the canonical create-placement transaction. Reachable in ordinary play: retail's per-object update_times channels are monotonic and do not reset when an item re-enters a container, so any item that ever had world presence — dropped once, picked back up, then split — carries nonzero values in exactly those two fields. The split pile then never appears. Fix is the honest value, not a placation of the predicate: a fresh split GUID has no movement history by construction, so both channels are zero in both projections. Deliberately NOT fixed by loosening HasConsistentCreateIdentityAndParent — the predicate was right and the producer was wrong. The route-6 test that documented the throw (SplitSourceWithRetainedMovementTimestamps_ThrowsInsteadOfRecovering) is renamed to …_StillRecovers and now pins the fix. It asserts more than "no throw": the result's movement channels must be ZERO in both projections, so the test cannot pass against a lenient-predicate workaround. Sabotage-verified in both directions — restoring the old BuildSpawn reproduces the exact original InvalidOperationException. Notable for the campaign record: this is a crash in the precise mechanism route 6's scoping cited as EVIDENCE that drops already converge on the canonical transaction. Reading the code said the path converges; driving it said it throws. The zero-production route was still correct — and building its tests anyway is what found this. Complete Release suite 11,020 passed / 4 skipped / 0 failed, unchanged from 1b484937 (the test flipped its assertion rather than being added). Neither known flake fired. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 16:48:41 +02:00
Erik	6dc7ba51ee	feat(physics): C4 route 4b-3 — remote teleport + cell-less through the canonical placement ... Flips the last remote classification (SetPosition: teleport-advanced and cell-less) onto 4b-1's RuntimeRemotePlacementDriveController, runs retail's teleport_hook before the placement, and deletes the legacy remote-teleport machinery. Contract: docs/research/2026-08-04-c4-route-4b-3-contract.md. Retail: MoveOrTeleport @0x00516330's branch @0x00516386 -> teleport_hook @0x005163EF -> SetFlags(0x1012) @0x00516414 -> SetPosition @0x00516420 -> return 1 @0x00516438. The hook @0x00514ED0 runs BEFORE the placement and regardless of its outcome. Retail places this branch unconditionally, at any distance and any contact state (arg4 is read only @0x0051638E, after the branch) — which is what retires AP-137's cell-less enqueue-vs-place delta. D1 — the classifier's cell-less input is now the PRE-merge committed cell. Retail's predicate is `this_1->cell == 0`, the BODY's own cell at MoveOrTeleport entry (this_1 is assigned from this @0x00516334). acdream fed the POST-merge canonical.FullCellId, which RefreshSnapshot -> RefreshDerivedState -> SetFullCell has already stamped with the accepted wire cell; a zero wire cell fails validation into RejectedData first. The shipped remote cell-less predicate was therefore dead code, not merely different from remotePlacementRequired. Threaded via a builder overload; route 1's overload is untouched. The graphical !IsSpatiallyVisible arm of projectionRequiresTeleportHook is deleted — a presentation predicate with no retail analogue that fired the teleport machinery on a routine hot path. Deleted: RemoteTeleportController (605), RemoteTeleportPlacement (85), RemoteShadowPlacementSynchronizer (49), their 1,709 lines of tests, the remotePlacementRequired predicate, the TeleportHookRequired plumbing, the legacy pre-operation ConstrainTo fallback, and the player arm's legacy !IsGrounded fallback. Net -2,030 lines. Structural fix (two independent Opus reviews, round 1 FAIL/FAIL): three of the four MAJORs were one defect — OnPosition carried two parallel inline copies of the routing tail (player-guid, NPC-guid) that had drifted. Extracted RunRemoteArmTail (3 call sites) and ApplyWireAirborneLeftoverBookkeeping (2), both branches now share one implementation. A1 ToConstraintArm mapped AirborneSnap -> AirborneNoOperation, so the NPC arm armed ConstrainTo ZERO times for an out-of-contact wire-grounded creature — a regression this slice introduced while closing a structurally identical hole. Now maps to NearInterpolate; switch made total with a throwing default proven unreachable. R1 D2's write-nothing shape existed on the player arm only; NPC packets fell through and wrote the body. Retail makes no player/NPC distinction. R2 report_collision_end(this,1) @0x00514F31 was bound to ShadowObjects.Suspend, a port of a DIFFERENT retail function (remove_shadows_from_cells) that teleport_hook never calls. Now routes to RuntimeCollisionReportingState.LeaveWorld, which wraps the private ForceEnd in an admission-blocking transaction so a DoCollisionEnd callback cannot recreate the contact table. R3/A2 A teleported NPC synthesized ServerVelocity from the teleport distance (~1,000+ m/s) and planned a run cycle from it. Both the install and RemoteServerControlledVelocityCycle.Apply now gate on !isTeleportRoute. BISECT HAZARD — A1's fix is correct only BECAUSE R1 landed. AirborneSnap is reachable wire-airborne on the NPC arm only while D2's shape is missing there. Reverting R1 alone silently inverts A1 into the opposite divergence: arming where retail returns 0. Revert both or neither. Also in the velocity hunk: the NPC block's two !IsPlayerGuid(update.Guid) guards were dropped when it was wrapped in `if (!isTeleportRoute)`. Safe — all five exit paths of the enclosing IsPlayerGuid block return, so the predicate is unconditionally false below it — but it was unremarked by both reviews. Register: AP-137 REWRITTEN (not deleted) to the surviving acdream-only divergences — null classification during the login window and Rejected* through UnroutedCatchUp keep a row. AD-42's RemoteTeleportController citation retired; AP-136/AP-138 writer lists corrected to the two surviving non-Position rebucket writers; AP-138 gains the teleport arm as a second producer of the visible-without-collision residual (retirement path remains #309). AP-135 is untouched and its two airborne bookkeeping writes are preserved on both arms. AP-131 does not retire; #276 does not close. Proof obligation 1: ParkCollisionResidents' overlap throw stays unreachable — the teleport arm adds packets to the same TryBeginExclusiveAuthoredPlacement one-operation-per-key machinery the far arm uses, opens no new operation shape, and every DeferredCell outcome cancels synchronously with restoreCancelledPark: true. The guarded property remains HasOldPrefixPlacementDebt's stall, not a throw (4b-1's B2 caveat stands). Correction to an earlier claim: LiveEntityPresentationController's _activePlacementOwners was NOT write-never at HEAD — remotePlacementRequired -> BeginPlacement -> Begin -> BeginAuthoritativePlacement was a live writer chain. It becomes write-never BECAUSE this slice deletes that chain, which is why deleting the dead half is behaviour-preserving. Probe: ACDREAM_PROBE_REMOTE_TELEPORT=1 emits one [remote-teleport] line per routed arm (guid, cause, hook-ran, placement status). TEMPORARY, strip with the probe family. Carried, disclosed not fixed: no dedicated bidirectional collision-partner test for R2 (the wiring, not LeaveWorld itself, is what lacks coverage); the stress test's teleport step drives hand-written field assignments rather than the canonical arm; the per-packet runTeleportHook closure allocation (network path, not the resolve path Slice I's 0 B discipline governs — file before route 5 adds a fourth call site). B2: IRuntimeCollisionReportObserver has zero production implementations, so retail's bidirectional DoCollisionEnd half still reaches no gameplay consumer — this fix closes the wrong-function binding, not that nobody listens. Complete Release suite MEASURED at 11,013 passed / 4 skipped / 0 failed (baseline 11,027/4/0; net -14 = ~33 deleted test cases against ~19 added). Neither known flake fired (#302 PortalProjectionTests GC-allocation, #308 NakEmissionTests wall-clock). STILL OWED: the two-client connected gate, which MUST use an NPC/creature teleport target. Both round-1 MAJORs lived on the NPC arm and the velocity cycle early-returns for 0x50xxxxxx guids, so a player target structurally cannot observe A1, A2, or R3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 16:00:10 +02:00
Erik	2eb39a0250	fix(physics): route remote Positions on contact, not walkability (AP-140) ... The two gates that decide whether an accepted remote Position is interpolated or hard-snapped read `Airborne`, which is `!Body.OnWalkable` — WALKABILITY. Retail reads CONTACT: InterpolationManager::adjust_offset @0x00555D30 gates its entire body on `transient_state & 1` @0x00555D52, so a retail body in contact with a non-walkable face still interpolates. The two predicates disagree in exactly one state — in contact, not on walkable ground — which 204d0ae0 turned from unreachable into ordinary. Before it, the per-tick forge made every non-airborne remote walkable by construction, so the disagreement could not occur. Both gates now read `!Body.InContact`: ApplyRemoteContactRouting's flight carve-out and OnPosition's player-remote arm. `Airborne` is deliberately NOT re-derived from CONTACT. That would perturb all five of its writers and contradict a pinned assertion in RemoteTeleportPlacementTests.Apply_PendingGroundToSteepContact_ (InContact: true, OnWalkable: false -> Assert.True(remote.Airborne)); a previous implementer attempted it and correctly backed out rather than editing the assertion. This narrower shape touches no existing test. AP-140's register row is retired in this commit, as the row itself specified. Honest scope: this is a faithfulness fix, not a visible one. ACE derives its IsGrounded flag with the same floor_z test, so during a slide it almost certainly reports not-grounded, the classifier returns NoPositionOperation, and neither arm is taken. Expect no observable change against ACE. Suite 11,027 passed / 4 skipped / 0 failed (baseline 11,023). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 11:53:48 +02:00
Erik	b1f914d508	fix(physics): restore presentation when a park is cancelled (#312) ... Regression from 7f1c1f5a (C4 route 4b-2). A remote player who recalled in, arrived, and stood still was permanently absent from the world render AND the radar while remaining fully simulated — 71 healthy physics ticks with contact and walkable, interpolation enqueues, equipment attached, chat visible. Route 4b-2 is the first commit that lets an ordinary remote UpdatePosition open a canonical SetPosition. A park publishes a synchronous Withdraw that tears down presentation registrations; only TryPublishPlace restores them. RestoreParkWithdrawal — added in the same slice — restores InWorld, the object clock, and canonical residency, i.e. the Runtime half only. Eight Opus reviews verified those three fields and the tests asserted exactly them, so the suite stayed green while the entity was invisible. Why it is intermittent: the presentation half IS restored incidentally by the per-packet prologue rebucket for a MOVING remote. It only sticks when the entity parks on its FINAL accepted Position and then goes idle, because ACE stops broadcasting for a stationary entity, so no later packet arrives to re-publish it and nothing else re-drives. The fix publishes a RuntimePlacementProjectionKind.WithdrawalRestored receipt on the one ordered placement stream, acknowledge-only in Runtime (the parked operation is already retired by CancelCoreDeferred), which the App sink maps to the exact inverse of its own TryPublishWithdrawal: the projection half (bucket, IsSpatiallyProjected, IsSpatiallyVisible, spatial indexes, RefreshPresentation) plus the publish half (_worldState, _worldEvents, _effectPoses, _localPlayerShadow, visibility sinks). Applied with commitPose: false, because the withdrawal never moved the sidecar; a test feeds a deliberately wrong position to pin that. Two alternatives were refuted on measurement, not preference. Routing the restore's SetFullCell through CommitCanonicalCell cannot fire on the shipped remote path at all — the prologue rebucket has already recommitted a non-zero FullCellId before the merge cancels the park, so no cell edge remains — and it never touches the publish half regardless. Extending RestoreParkWithdrawal directly reduces to the same receipt, since Runtime must not reach behind the host sink. Gated on the entity ending the rollback canonically whole (FullCellId != 0 && InWorld) rather than on residencyRestored, which is false on the shipped remote path and would have made the fix a no-op. AP-136's quiescing-prefix refusal arm is preserved: no receipt, entity stays withdrawn. Corrects my own framing of the defect: _worldState/_worldEvents/_effectPoses are lost but are NOT what kills render and radar (_worldState is the plugin IGameState; _effectPoses is the pose registry, not entity.MeshRefs). The load-bearing casualties are the visibility sinks and the IsSpatiallyProjected/IsSpatiallyVisible + bucket removal that gates the radar. Register: AD-63 filed (selection deliberately not restored — user intent), AP-136 amended (its "restored visible" claim covered only the canonical half; the gap was a defect, not a divergence). ShadowObjectRegistry.Suspend stays out of scope per AP-136. Seven-revert discrimination table including one that proves the test is not merely re-checking the bucket. Suite 11,023 passed / 4 skipped / 0 failed. Live gate is user-run and folds into #309: two clients, ACDREAM_PROBE_PARK=1, recall a remote in and let it stand still; acceptance is [park-restore] ... presentation=True for that guid plus a visible model and a radar blip. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 11:21:45 +02:00
Erik	204d0ae047	fix(physics): remote bodies slide on steep faces instead of freezing (#32) ... A remote observed in acdream landed on a sloped roof and froze; the server slid on, the gap passed AP-87's 4 m threshold, and the body snapped — the visible blip. Live probe capture, two adjacent ticks 63 ms apart: t=88420671 rsInContact=True rsOnWalkable=False rsIsOnGround=True bodyCpNz=0.6097 floorZ=0.6642 steep=True gravity=True vel=(2.146,2.264,-3.549) t=88420734 contact=True onWalkable=True <- forced against the sweep gravity=False <- cleared velBeforeZero=(2.146,2.264,0.000) moved=0.0000 <- and every tick after The roof is 52.4 degrees against a 48.4 degree limit, so acdream's classifier was CORRECT and was then overruled. Four independent links each froze the body on their own: a per-tick force of Contact|OnWalkable, a per-tick velocity zero, a Gravity clear at landing, and a landing edge testing IsOnGround (= inContact || ...) instead of OnWalkable. The tick called HandleAllCollisions alone — the tail of SetPositionInternal without its prefix. Retail simulates remotes locally and derives these bits rather than asserting them: CPhysics::UseTime @0x00509950 iterates the whole object table; update_object @0x00515D10 gates only on parent/cell/FROZEN with no is_player fork; SetPositionInternal @0x00515330 sets CONTACT from contact_plane_valid @0x00515430 and ON_WALKABLE from contact_plane.N.z vs floor_z @0x00515465-@0x0051548E before handle_all_collisions @0x005154FE; set_on_walkable @0x00511310 fires HitGround @0x00511364 / LeaveGround @0x00511346 edge-triggered with no ownership gate; calc_acceleration @0x00510950 zeroes only when CONTACT && ON_WALKABLE && !Sledding @0x0051096B; calc_friction @0x0050EE70 returns at its first line when ON_WALKABLE is clear. acdream had copied retail's airborne no-op WITHOUT retail's local simulation. The fix is mostly deletion: stop forging the transients, stop discarding the authoritative velocity, stop clearing Gravity, and route the remote tick through the same SetPositionInternal commit TickHidden and the local player already use, with the landing edge derived from the sweep's own OnWalkable. AP-87's threshold and conditions and InterpolationManager's node_fail_counter snap-to-tail are deliberately untouched — this removes the CAUSE of the divergence rather than weakening the backstop. Cross-checked against ACE: its only creature-side VectorUpdate emitters are the jump broadcast and spell projectiles, so integrating the wire velocity cannot double-move a walking remote; and PhysicsGlobals.DefaultState already carries Gravity, so deleting the manufactured State |= Gravity is safe. Register: AP-81 narrowed (its GRAVITY half retired outright), AP-87 annotated, AP-139 filed (the interpolation-queue clear on the landing edge), AP-140 filed (the two routing gates select snap-vs-interpolate on walkability where retail uses CONTACT — adjust_offset @0x00555D30 gates on transient_state & 1 @0x00555D52). AP-140's follow-up is deliberately shaped as "point the two gates at Body.InContact", NOT "re-derive Airborne", which would perturb five writers and collide with a pinned RemoteTeleportPlacementTests assertion. Three gaps recorded in #32 rather than papered over: the new LeaveGround dispatch is untested for chatter; a persistently !Ok transition can latch a remote airborne; and — the visual-gate watch item — the deleted forge was a blanket guarantee of Contact|OnWalkable, and contact_allows_move @0x00528dd0 silently refuses action animations without both, which is the literal root cause of closed #270. Retail-correct on a steep face, a regression anywhere else. 10 discriminating tests over a real PhysicsEngine landblock whose contact normal Z is 0.61 against FloorZ 0.6642 — the live roof's exact relationship. Suite 11,019 passed / 4 skipped / 0 failed. Includes the temporary ACDREAM_PROBE_REMOTE_LANDING / ACDREAM_PROBE_REMOTE_SLIDE probe family that produced the capture above; strip with the family. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 10:21:16 +02:00
Erik	7f1c1f5aa6	feat(physics): C4 route 4b-2 — remote far snap through the canonical placement ... Flips the SetPositionSimple classification (contact, PlayerDistance >= 96 m) for remotes onto 4b-1's drive controller and deletes both legacy far blocks, both duplicated 96f/4f constant pairs, and both `?? Vector3.Zero` fabrications. The 4 m constant now exists exactly once. Teleport and cell-less stay legacy for 4b-3. Retail: MoveOrTeleport @0x00516330's far branch runs StopInterpolating @0x005163CB before SetPositionSimple @0x005163D9 and returns 1 @0x005163E8 regardless — the SetPositionError is discarded — so HandleReceivedPosition arms ConstrainTo @0x00454272 post-move on commit AND on failure. The x87 parity decode at @0x00516393-@0x0051639E puts exactly 96.0 on the far branch. SetPositionSimple @0x005162B0 builds flags 0x1012 at @0x005162C4. Non-commit outcomes still advance the body, because retail's SetPositionInternal @0x00515BD0 commits the destination via store_position @0x00515CE2 when no cell resolves. The partition is by STAGE, not heuristic, enforced by an exhaustive switch: Refused/Contention/NotApplicable/RejectedPreparation store (the placement never executed); Committed/Deferred/RejectedByPlacement do not (the engine ran and refused, matching retail's non-storing returns @0x00515CB2 and @0x00515CD5). Without this a refused far snap froze the remote with an emptied queue. Also fixes a shipped defect this route made live: ParkDeferred's quiescence parks withdrew the entity (InWorld=false, clock suspended, residency removed) and were never restorable, while Forget(restoreCancelledPark: true) runs for every accepted Position on every entity. The restorable decision now lives inside ParkDeferred AFTER SnapToCell, reading body.CellPosition.ObjCellId — the value RestoreParkWithdrawal actually restores at — against every live quiescence rather than one minimum-OperationId token. The three pre-snap fields are hoisted into locals because SnapToCell ends with InWorld = true. ParkCollisionResidents passes restorableOnCancel: false explicitly; the plain unplaceable park is provably unchanged. RestoreParkWithdrawal re-tests the prefix at restore time so a retained route-2 park cannot re-admit into a prefix that began quiescing during the park. CanAttemptDestination is retained as an OPTIMISATION only, with the two Core predicates it cannot reproduce written down at the pre-flight, plus the two properties that depend on it staying there. Four fix rounds and eight Opus reviews. The slice was fully green at 10,990, 10,997 and 11,004 while containing real defects — a frozen remote pinned as correct by its own test, a fallback that over-wrote on the exact retail paths that decline to store, and a park guard incomplete on two independent axes. Register: AP-137 (leftover classifications take AP-87's catch-up; states the cell-less enqueue-vs-place delta deferred to 4b-3, that RejectedData is applied anyway, and the headless divergence), AP-138 (the refusable far placement), AP-136 narrowed to match the relocation. #309's acceptance steps rewritten — step 5 previously asserted a recovery the code does not perform — and gated on a new ACDREAM_PROBE_PARK=1 signal so the check cannot pass while broken. Suite 11,009 passed / 4 skipped / 0 failed against a measured 10,968 baseline. The 10,973 figure recorded earlier was wrong and is corrected here. Connected gate outstanding: the two-client far-snap walk and #309. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 07:55:56 +02:00
Erik	2e8e09acd0	feat(physics): C4 route 4b-1 — remote placement infrastructure (dormant) ... Builds the machinery route 4b-2 and 4b-3 will flip on, and changes no remote behaviour: it has no production caller, so RemotePlacementDrivePendingCount is provably 0 and IsConverged is unchanged. Five pieces: a per-entity remote placement owner (RuntimeRemotePlacementDriveController), a Position-time service-window guard with a Runtime interface plus BOTH host implementations, N3's headless RetryPending pump, parked-count observability in the ownership ledger, and the service-window optimisation that avoids parks we can cheaply predict. Landed alone because it is where the park-withdraws-the-entity failure was decided; that decision is fixed at the source in the preceding commit and must not share a review signal with a behaviour flip. Two parts of route 2's controller are deliberately NOT ported, both verified against retail rather than assumed. There is no ack: SendPositionEvent is called only inside HandleReceivedPosition's local-player FORCE_POSITION gate @0x0045400C-@0x00454091, and the remote arm @0x0045414D has no equivalent. There is no re-issue funnel: retail never re-attempts a position it could not apply — stale timestamps merely bump error_count @0x004542AC — and re-issuing packet N after N+1 has merged would apply a pose the newer packet already superseded, which is correct for a one-shot ForcePosition and wrong for a 5-10 Hz stream. The service-window guard is an OPTIMISATION, not the correctness mechanism. The original contract had it the other way round, justified by a claim that retail cannot represent "arrived but not placeable" — false, and corrected in the review findings: retail's GotoLostCell/reenter_visibility path represents it exactly. A pre-flight guard also cannot be complete, because Core defers on the entity's CURRENT cell, on the swept QueriedCellIds footprint spanning neighbouring landblocks, and on residency evaluated after AdjustToOutside — conditions only Core can see. Review found and this commit fixes: DetachRoute cleared two maps of LIVE Core operations without cancelling them (route 2's AbandonPending is the correct mirror, not the first-entry controller) and its test asserted that blindness as convergence; the headless predicate answered "can ever publish" rather than "is published", and after the first fix still matched only 1 of the 9 landblocks this host publishes; OwnsPlacement admitted remote top-level Creates until gated on the Teleport flag as well as the disposition; Advance re-submitted without re-checking the window; and four comments cited a report that did not exist. Contract item 6 is met by the structural proof, not the earlier test: HasOldPrefixPlacementDebt refuses collision-prefix mutation permission before ParkCollisionResidents is ever entered, so its overlap throw is unreachable. That same mechanism is the unbounded stall filed as #310, which 4b-1 does not bound — it only avoids widening it. #311 files the remaining per-tick allocation in RetryPendingProjections; the early-out for the empty-FIFO case landed via a new HasPendingReceipts accessor so hosts still never touch .Placements. directly. Gates: complete Release solution 10,973 passed / 4 skipped / 0 failed (baseline 10,938). Four review rounds; every fix discrimination-verified by revert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 04:08:19 +02:00
Erik	eeec4fb42a	diag(physics): remote landing-edge probe; record the two live jump defects ... The user live-tested route 4a and reported two defects on player remotes: a remote holds the falling animation after landing before finally landing, and a remote jumping onto a house plants on the roof where retail slides off, then blips to the slid-down position. Neither is a route 4a regression. Do NOT revert 44830a0e — reverting would restore the per-packet render slam 4a removed without touching either defect. Bug B's root cause is identified and already covered by open issue #32, whose text names both symptoms in one sentence. Both landing sites assert TransientState |= Contact | OnWalkable unconditionally, where retail derives it from the contact plane — CPhysicsObj::SetPositionInternal @0x00515330 (`if (contact_plane.N.z < floor_z) set_on_walkable(0) else set_on_walkable(1)`). A steep roof is contact but NOT on_walkable; asserting both suppresses the slide response, so the body sits until the server's positions walk 4 m away and AP-87's threshold snaps it. That is the blip. Verified byte-identical pre-4a via `git show 19d95094:`. Bug B's *visible shape* IS 4a's: pre-4a every packet slammed the render entity to the wire pose, so a stuck body flickered toward the true sliding position 5-10x per second — jitter rather than a clean hold. Bug A stops at the goal's stop-condition rather than getting a speculative fix. Three hypotheses with non-overlapping fixes; picking wrong means changing a retail-ported gate on a guess. Retail's mechanism is already fully decoded, so what is missing is OUR runtime state — no cdb trace against retail is needed. Adds ACDREAM_PROBE_REMOTE_LANDING (PhysicsDiagnostics, read once at startup per the diagnostic-owner rule, one bool check when off). It logs both landing sites immediately before HitGround, and — the most diagnostic signal — emits a separate line when a site is reached but the gravity gate is about to no-op, which is hypothesis 1 (a wholesale Body.State write wiping the transient Gravity bit mid-air, exactly AP-81's stated risk). Temporary instrumentation, marked for stripping once the evidence is in. Evidence recorded rather than new bugs filed: #32 gains the observation, the root cause and the #173/AD-10 dependency caveat; AP-87 gains a live instance of its stated risk; AD-10's stale file:line is corrected to RemoteMotionCombiner with a note that its terrain-only normal cannot see a house roof at all. Also files #308 — a SECOND flaky test, distinct from #302, which was twice misattributed to it before being written down. #302 is a GC-allocation assertion in App.Tests; #308 is a wall-clock deadline loop in Core.Net.Tests that fails only under full-suite CPU contention (0 failures in 4 isolated runs). Conflating them hides one, and an agent told to "ignore the known flake" would wave through a real transport regression. Gates: complete Release solution 10,938 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 01:10:03 +02:00
Erik	44830a0eb3	feat(physics): C4 route 4a — remote steady-state Position through the seam ... Routes the classifier's two NO-PLACEMENT remote branches — Interpolate (contact, PlayerDistance < 96 m) and NoPositionOperation (no contact) — through a Runtime-owned seam, and fixes the two divergences they carried. Teleport, far-snap and cell-less stay on the legacy App path; 4b owns them. Route 4 was split into 4a/4b after scoping put the whole route at 1,500-2,500 lines against a ~400 budget. 4a's branches perform no SetPosition, so this slice carries no deferred-cell park, no service-window guard and no allocation exposure — which is what made the split worth doing. Divergences fixed, both previously unfiled: * D1 — the NPC airborne branch hard-snapped Body.Position/Orientation and branched on the client-tracked rmState.Airborne, never consulting the wire IsGrounded bit. Retail's MoveOrTeleport @0x00516330 returns 0 at 0x0051636D and writes nothing. Player remotes were already correct; NPCs were not. * D2 — ConstrainTo was armed before the operation, unconditionally, so it fired on the airborne no-op retail skips and anchored to the PRE-move position. Retail arms it at 0x00454272, only when MoveOrTeleport returns nonzero, anchored to &arg2->m_position read live, i.e. post-move. AP-87 and TS-44 were carried deliberately, not delegated away. AP-87's three conditions — including firstUp, which one round silently dropped — are preserved as an explicit acdream policy layer applied AFTER the classifier commits to Interpolate; the two previously separate player/NPC copies are now one. TS-44 stays an NPC-only caller gate; extending sticky suppression to player remotes has no retail basis and no live evidence, so it was declined rather than absorbed. Landing is explicitly carved out of 4a's ownership on both arms. A landing packet classifies Interpolate, so an ordering slip would ENQUEUE a body that must PLANT and a creature knocked off a ledge would glide down over a packet interval. The carve-out is a named entry point returning AirborneSnap/SteadyStateInterpolate/ Legacy precisely so the PRECEDENCE is observable and testable rather than implied by statement order — that is how the slip happened once and was caught. The player/NPC asymmetry on landing is real and NOT resolved here: retail draws no such distinction, but converging them is a behaviour decision needing its own evidence. Filed into the 4b plan. Register: AP-135 filed for the two bookkeeping writes the airborne branch deliberately retains (rmState.CellId, LastServerPos/Time) — not retail's model, but load-bearing for our catch-up sweep and staleness timer, and verified not to be a canonical cell commit for ordinary remotes. AP-87 and TS-44 rewritten to describe the code. Honest remainder: App still owns branch selection, the airborne return, the cell write, the entity write and the shadow publish, and headless satisfies "both hosts drive the identical entry point" only vacuously since it returns early for remotes. That is written into the 4b bullet rather than left implicit. Cost: 364 non-comment production lines, 91% of the ~400 budget — the split did isolate the cheap half, but not by much. Do not carry "well under" into 4b's scoping. Gates: complete Release solution 10,938 passed / 4 skipped / 0 failed (pre-4a baseline 10,909). Four review rounds; the first three each introduced a new behavioural defect while fixing another, and each left a comment asserting behaviour that no longer matched — the final round's precedence matrix was traced cell-by-cell against HEAD with only the D1-intended difference. App tests call production entry points against a real WorldEntity and real classifier output, closing route 2's #292 gap rather than repeating it. Connected acceptance NOT run — needs a live second character. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 00:19:05 +02:00
Erik	bc0077a55f	fix(combat): #298 — admit player targets to melee/missile attack and the camera ... Selecting a PKLite player and attacking did nothing: with auto-target on it retargeted to the nearest monster, with auto-target off it logged "combat: attack ignored; no creature target found". Spells on the same target worked, which was the clue. Root cause: CombatTargetPolicy.IsHostileMonster:31-33 rejects any candidate carrying BfPlayer BEFORE reaching ObjectIsAttackable, so the both-PKLite pool match at SelectedObjectHealthPolicy.cs:70-71 was unreachable for players. Melee and missile targeting never supported player targets at all — the gate is named IsHostileMonster and does exactly what it says. Nobody could hit it until 69ba9486 made PK Lite reachable. Retail uses ONE predicate for monsters and players, with no player exclusion: ClientCombatSystem::ExecuteAttack @0x0056BB70 gates unconditionally on ObjectIsAttackable @0x0056A600 (creature type, Free-PK short-circuit on either side, then IsPlayer -> bothPK || bothPKLite, else BF_ATTACKABLE with pets excluded). acdream already ported that predicate verbatim; it was simply unreachable. The fix SPLITS the two concerns rather than relaxing the shared predicate: explicit-target admission routes through ObjectIsAttackable, while auto-target ACQUISITION keeps the monster-only gate. That is required by register row IA-19 — explicit product direction that Auto Target must never select NPCs, players or pets. IA-19 is not overridden here; its own justification promises "manual player-selection commands remain available", and that promise was never implemented, so this makes the row true. Review confirmed no path lets auto-acquisition select a player: every automatic Select is fed by a FindClosest* filtered through IsHostileMonster. Review also found a second site with the same bug, which the first pass froze in place on my instruction: retail gates combat-camera tracking on the SAME predicate as the attack. ClientCombatSystem::UpdateTargetTracking @0x0056A950 reads GetAttackTarget() then gates CameraSet::TrackTarget on ObjectIsAttackable. Ours used the monster-only gate, so with ViewCombatTarget on by default the attack would land while the camera refused to track the opponent — user-visible in exactly the duel this fix enables. GetCombatCameraTargetPoint now uses the wide predicate. IA-19 does not reach the camera: it performs no acquisition, only presentation on an already-chosen target. The first pass had added a source comment asserting IA-19 covered it; that comment and the matching text in docs/ISSUES.md are corrected, since a wrong citation is how a real divergence becomes invisible. Depends on 9b1e6fc6 (#297): the both-PKLite arm needs the LOCAL player's own bit to be live. Review confirmed both admission sites read ClientObjectTable on every call, so this is not inert in production. Newly reachable and now pinned: ObjectIsAttackable's pet-exclusion arm, which CombatTargetPolicy rejected before it could ever run. Follow-ups filed: #304 (SelectionInteractionController.GetSelectedOrClosestCombatTarget has no production caller — one of the two widened call sites is dead code), #305 (HeadlessGameplayOperations has the identical pre-existing bug, so the graphical/headless hosts now diverge). Gates: complete Release solution 10,904 passed / 4 skipped / 0 failed (baseline 10,900). Adversarial + retail-conformance review PASS after one FAIL round; the predicate was re-verified branch-for-branch against 0x0056A600 since it goes live here for the first time. Camera fix discrimination-verified by revert. Connected acceptance NOT run — needs a live two-client PKLite session. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 21:29:15 +02:00