1482 commits

Author	SHA1	Message	Date
Erik	6eaa490bb3	feat(audio): Campaign A slice A4 — the interface sound bus ... Retail's UI sound bank was absent, so three families of cue were silent: the portal enter/exit stingers, the AdminEnvirons dungeon atmosphere (chanting, drums, whispers, thunder — what players remember as dungeon 'music'), and every other interface slot. The bank's DID is not a literal anywhere in retail: GetUISoundTable @0x00563FB0 asks GetByEnum for enum slot 7, and DBCache::GetDIDFromEnum @0x00413940 resolves it through two EnumIDMap hops off the portal dat header's master map. UiSoundTableResolver walks that chain the way RetailCursorResolver already walks it for cursors. Against the shipped dats it resolves to 0x2000004B, and that table holds exactly the 32 UI_* slots (UI_EnterPortal 0x6A .. UI_Thunder6 0x8A) — content that confirms the walk independently of the decode. UiSoundTableResolutionTests pins the walk, the DID, and the content, and skips when dats are absent. Two corrections to the research along the way. The lane-5 note recorded GetByEnum's arguments transposed: the 0x22 it called a fileType is the CACHE type (CLOCache(cache, CSoundTable::Allocator, 0x22)) and the real second-hop key is 0x10000003; walking it the other way finds nothing. And its claim that the interface volume pref applies is wrong — GetAttenuation with ambient=0 multiplies by the EFFECT knob, so retail's interface_sound_volume stays the dead knob lane 1 byte-decoded it to be. EnvironSoundCueMap is an explicit 21-case table read straight out of Handle_Admin__Environs @0x0055DE20, not arithmetic: codes 0x65..0x72 sit 0x11 below their SoundType, but 0x73/0x74 have no case, so 0x75 lands on UI_Squeal (0x84) where an offset gives 0x86, and the switch ends at 0x7B with no 0x7C case. Verified case-by-case against the decomp rather than from the lane note, whose tail table was ambiguous. Cues are attached where retail plays them: the teleport-animation boundary for the portal pair, and the AdminEnvirons handler for the stingers. PlaySoundFromCenter's pan-0 / distance-0 shape is what PlayUiWave already implements after A2. Retires TS-54. Narrows AP-115 to its notice-presentation residual. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 22:22:09 +02:00
Erik	8bc458fb88	feat(audio): Campaign A slice A3 — the server sound channel (0xF750) ... acdream never parsed retail's Sound event, so every server-driven cue was silent: melee hits and wounds, wield/unwield, pickup/drop, lockpicking, lifestone bind, spell resist, trap triggers, item mana depletion. SoundEvent parses the 16-byte message (guid, SoundType, f32 volume) whose layout three oracles agree on: retail CM_Physics::DispatchSB_SoundEvent @0x006AC760 reading buf+4/+8/+0xC, ACE's GameMessageSound at declared length 16, and holtburger's PlaySoundData. Playback reuses EntityEffectController's existing per-guid queue rather than adding a second one, because retail routes sounds through the SAME CObjectMaint blob queue as F754/F755: an event for a guid the client does not know yet is parked and drained by HandleCreateObject, so a creature that spawns and immediately grunts still grunts. Dropping it — the obvious alternative — would silently lose the cue. Sound joins Direct and Typed as a third PendingEffect kind so one readiness edge releases the whole mixed stream in order. AudioHookSink.PlayServerSound reproduces two decoded asymmetries with the animation-hook path: the sound plays at the WIRE volume and the SoundTable entry's volume is ignored (the hook path does the opposite), while the entry's probability still gates it and its priority still drives eviction. An object with no SoundTable plays nothing, matching CPhysicsObj::play_sound @0x0050F460's early return. The no-window host parses and discards, exactly as it does for F754/F755 — sound is presentation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 22:07:23 +02:00
Erik	e42b99482e	feat(audio): Campaign A slice A2 — retail's 2D pan+gain mixer replaces AL 3D ... Retail is not a 3D audio engine. Every gameplay buffer is created with m_3D = 0 and the DirectSound 3D listener the client sets up is dead code; spatialization is two CPU scalars per voice, frozen at emission. This slice ports that math and demotes OpenAL to a voice bank. RetailSoundMixer (new, Core) carries the byte-decoded curve from SoundManager::GetAttenuation @0x00550020: g = dist < 5 ? vol : 25*vol/d2, clamped to 1 BEFORE the single master multiply, db = ceil(20*log10 g), with a hard -50 dB floor at which retail does not start the voice at all (audible radius ~94.2 m at unity). Pan is PlaySoundInternal @0x00550170's (int)(-15*sin(delta-bearing)) in whole decibels, truncating toward zero, forced to dead centre when (int)distance < 5, with no front/back and no elevation cue. Every AL source is now source-relative with rolloff 0 and the global distance model is None: AL's InverseDistanceClamped was first-power (2/d), quieter than retail up close and far louder at range with no cutoff whatsoever. That was the largest audible divergence in the subsystem (AP-28, retired here). RetailVoicePool (new, Core) ports the allocator at 0x0054FEC0: ring scan for a free or finished slot, then evict the first slot whose DAT priority is strictly lower, else drop. Eviction compared GAIN before, so a loud unimportant sound could silence a quiet important one. It lives in Core because the engine's play path talks to native AL handles and could not be tested; the pool now has 12 conformance tests. The listener keeps using the camera position, which the decode shows is retail-faithful (SmartBox::set_viewer @0x00452D36 hands the same collided camera Position to SoundManager) — only the heading extraction changes, since retail reads one compass bearing and never a forward/up basis. An earlier draft of the plan called this a defect; corrected in the plan so it is not fixed backwards. Opus review found and this commit fixes: a linear pan-to-azimuth mapping that saturated to full separation at 30 degrees (OpenAL Soft's own speaker angle) where retail gives 15 dB — now inverts the constant-power pan law, so full deflection reaches 0.776 of the arc and both channels stay live; the stale FUN_00550ad0 / gain-eviction class header, which contradicted the register row this commit writes; missing discriminating tests for clamp order and pan truncation; dead PlayingGain state whose comment invented a retail symbol; and a third in-tree copy of Position::heading, now delegating to MoveToMath.PositionHeading. MasterVolume folds into the mixer's one multiply instead of AL listener gain, so the cutoff, radius and dB quantisation move with the slider. Register: AP-28 retired; AP-173 (pan law), AP-174 (volume taxonomy), TS-64 (two unimplemented sound prefs), TS-65 (volume-squared quirk, applied on the ambient path only) filed. Research note corrected twice where its summary contradicted its own decode (30 m dB, floor vs trunc). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 21:58:50 +02:00
Erik	c69b3bde04	fix(audio): Campaign A slice A1 — retail's sound probability gate (#355) ... The SoundTable probability field is a Bernoulli play/skip gate applied at the play site (SoundManager::PlayProbability @0x005500E0), not a selection weight — and variant selection (SoundManager::GetSound @0x00550680) is a uniform index over (n-1) that ignores probability entirely. SoundCookbook did the opposite: a cumulative-distribution walk weighted BY probability, short-circuiting single-entry lists before rolling at all. A dat census says 4,183 of 4,184 entries are single-entry and 686 of those carry probability < 1.0, so the gate was categorically absent: Speak1 idle chatter authored at 0.05 fired every trigger (~20x too often), wound/attack/ swoosh variants never dropped, and six 0.0001 entries always played. Split into retail's two steps (PickVariant + PlayProbability, composed by Select) over a new ISoundRandom modelling both retail roll ranges: the variant roll clamped below 1.0 (0x00797D48) and the gate's 1/32767 grid, which is why 0.0001 resolves to ~1.2e-4. PickVariant reproduces retail's (n-1) off-by-one verbatim per the port-faithfully rule — the last variant of a multi-entry sound is unreachable, costing exactly one wave (0x0A00051E) in the shipped dats. Also removes invented mechanism this review disproved: the dead Core SoundEntry/ISoundCache scaffold (PitchMin/PitchMax, Loop, Is3D — retail never calls SetFrequency, never sets the loop flag, and creates every gameplay buffer 2D), the engine's pitch plumbing, the int 0..7 priority cast (the dat field is a float in [0,1]; 4,100 entries collapsed to 0), and the clamp-at-the-field on volume (an unbounded gain retail clamps only after the distance divide). Tests rewritten as conformance against the disassembled values, replacing a self-referential suite that pinned the wrong model. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 21:28:16 +02:00
Erik	6bb4cfa795	feat(ui): the spell-bar drop ring — retail's authored drag-accept state, and the ring exposed a real drop off-by-one ... The green ring is retail's own art: every UIItem cell carries an authored DragAccept child (catalog 0x21000037, child 0x1000045A), and the spell bar's drag-over handler (SpellCastSubMenu::OnItemListDragOver @0x004C5990) flips it to the Accept state (0x10000040 -> surface 0x060011F9) for any spell payload. Ported through a per-slot SetDragAcceptVisual seam + a catalog DragOverAcceptance hook; other lists are untouched (null acceptance = neutral). A polarity error in our older docs (Accept/Reject state ids swapped) was corrected against three independent sources; the shipped art was always right, only the labels lied. The ring shares ONE landing computation with the drop (FavoriteDropIndex) — and that requirement exposed a genuine #354 off-by-one: the empty-tail path double-applied the -1 adjustment (retail gates it on the lift's removal @0x004C7157), landing a reordered spell second-to-last instead of last. Fixed; discriminator-verified both ways. AP-172 narrowed + its false empty-tail claim corrected. Clean-room complete solution: 11,545 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 20:18:51 +02:00
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	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	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	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	609a2dfda0	fix(runtime/core): Slice 5.3 review corrections — retirement/transit close, per-unit pricing, guarded auto-close dispatch ... The adversarial review's three blocking findings, each fixed at root: 1. A vendor session now CLOSES when its entity retires (despawn, death, ObjectDelete) and at teleport BEGIN (HasPendingTeleportStart || IsTeleportActive at the existing per-frame seam — both hosts funnel through RuntimeWorldTransitState.TryQueueTeleportStart, which flips the pending flag strictly before activation). The previous permissive early-return stranded the session forever: panel pinned to a stale guid, ActiveVendorId swallowing Use for the rest of the session. 2. VendorShopItem carries the desc's stack size, and VendorPricing.PerUnitValue ports retail's stack-total division (VendorProfile::VendorSellPrice 0x005D1B00: <= 0 guard, integer division) — a stack of 50 arrows now prices per arrow, not at 50x. 3. VendorState.Close() guards its observer fanout with the dispatcher's catch-and-log semantics — a throwing panel listener can no longer propagate into the unprotected per-frame path. Register honesty rides along: the 0.6 m UseRadius fallback was acdream's invention (ACE's CheckClose has no fallback; retail passes the raw authored radius) — removed, the watcher now uses the raw radius and AP-160's citations are corrected and extended with the accepted-position-snapshot cadence; AD-72 files VendorPricing's double-vs-x87-extended narrowing (AD-33's class, bounded by the ±0.1 margin). Nine tests added. Clean-room complete solution: 11,311 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 16:15:57 +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	70f37dbd5c	feat(core): Slice 5.2 — VendorState + retail's exact vendor price math ... VendorState sits beside ExternalContainerState (contract decision 1) with the same shape: private setters, Changed event, Reset with AggregateException fanout; domain-shaped like ContainerContentEntry since Core cannot reference Core.Net. No Runtime wiring, no UI — 5.3's job. VendorPricing ports ShopSystem::BuyPrice/SellPrice (0x006B6120/ 0x006B6180) faithfully: retail's literal three-way branch survives, including the unreachable-with-real-data negative -1 sentinel that ACE's Math.Max(1, ...) collapse erases — equivalence for legitimate inputs is hand-proven and documented rather than silently assumed. Seven conformance tests with hand-derived golden values (float32 semantics verified independently), covering rate=1.0, fractional rates, value=0, the rounding-sensitive halfway case, stack multipliers, the ItemType rate-override branch, and the sentinel. Clean-room complete solution with 5.1+5.2 in place: 11,291 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 15:05:47 +02:00
Erik	e45c95b06c	feat(net): Slice 5.1 — ApproachVendor (GameEvent 0x0062) inbound parser ... VendorApproach.TryParse reads the vendor profile and the item list per the byte-verified field table (research doc §A.2), each item through the shared PublicWeenieDescParser from 5.0 — zero duplicated parsing. One wire detail the research table did not spell out, found by re-reading ACE's writer and confirmed independently in Chorizite's generated readers: every object body is 4-byte-aligned at its END, so back-to-back vendor items need an explicit AlignTo4 between entries (CreateObject never needed it — nothing follows its body). Pinned by a dedicated test forcing a real 2-byte misalignment via AmmoType. Stack-size sign extension cross-checked against holtburger. Six tests: field-order with distinct literals, empty list, and truncation at each structural boundary — mid-item-tail truncation deliberately inherits 5.0's established non-throwing partial-item contract instead of asserting null everywhere. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 15:05:47 +02:00
Erik	fa0c053ebf	docs(physics): #347 closed WITHOUT a code change — retail's glide alternates exactly as ours does; AD-70 retired as a wrong inference ... The round-2 cdb capture is decisive: during a live retail glide, edge_slide fired ~1.5 times per find_transitional_position — the arm/move alternation's exact signature (3 entries on the arming tick, 0 on the moving tick) — with cliff_slide in lockstep, step_down at 2.5x, step_up 0, and every stack sample on our identical call path. cliff_slide's bytes match our port and ACE's (compare constant at 0x794610 verified 0.0), and the user could not distinguish the two clients side by side. The "retail redirects within the tick" premise misread round-1's set_sliding_normal cadence (per-event, not per-tick, so its 1:1 ratio with edge never discriminated anything). The alternation-tolerant assertion in Issue345SteepSlopeGlideTests is therefore the CORRECT retail-shape pin from both sides; its comment now cites the capture instead of calling the shape a residual. The #269 note is honest the other way: the hope that a within-tick port would explain that feel residual is withdrawn with the premise. The temporary Scratch347 diagnostic is deleted. Capture evidence: 345-glide-stacks.cdb.log (repo root, untracked, cited from the contract's RESOLUTION section). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 14:05:53 +02:00
Erik	535f41bbdf	docs(physics): #347 premise revision — retail may alternate too; ftp:edge ratio is the discriminator ... The cliff_slide arms are conformant in ACE, our port, and the bytes (compare constant at 0x794610 verified 0.0), the round-1 slidn:edge ratio (538:594) refutes a retail retry storm, and the user's side-by-side speed observation fits alternation. Round-2 cdb script now counts find_transitional_position; H-A (identical, retire AD-70) vs H-B (within-tick yield) resolves on one ratio. The temporary Scratch347 diagnostic test rides along until #347 closes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 13:42:14 +02:00
Erik	ab89ebdf92	fix(physics): #345 — a grounded mover glides along a too-steep face; validate_walkable's return is scoped as retail's bytes scope it ... Retail's OBJECTINFO::validate_walkable @0x0050d010 initializes its return slot to OK (0x0050d025) and assigns ADJUSTED only inside the below-plane guard, immediately after the push executes (0x0050d249). The guard-fail path — grounded, OnWalkable, plane too steep — jumps past the contact write, the push, and the assignment (0x0050d1b9 -> 0x0050d251): retail deliberately IGNORES the steep plane at primary validation so the insert proceeds, the step-down phase fails on the steep landing, and the edge family produces the per-tick lateral glide. ACE flattened this into an unconditional return Adjusted (ObjectInfo.cs:169) and we inherited it; our TransitionalInsert then retried the byte-identical Adjusted forever — the user's stop-instead-of-slide. Evidence chain: the user's retail observation (the axiom), the live cdb glide profile (edge_slide/cliff_slide 594 each in lockstep, step_up 0), the D0 implementer's correct STOP (fixtures reproduced the stuck fingerprint while faithfully executing the ACE-shaped reading — refuting the reading, not the code), and the capstone byte-decode both Opus reviewers re-derived independently, including the stack-slot frame arithmetic and every ret site's eax. The conformance fixture is the live topology: flat and steep terrain triangles sharing ONE cell's diagonal (a cell-boundary face does NOT reproduce the loop — the cell-scoped primary sample never validates a neighbour's triangle — and is pinned as supplementary). Sabotage: restoring the unconditional Adjusted reds the discriminator with the exact stuck position (0.325 m lateral, 28/30 stuck ticks vs 2.602 m / 14/30 fixed; reviewer B's independent five-angle table is monotone 10-85 degrees). Stuck ticks are counted from positions so the assertion survives the eventual probe strip. In-game glide gate PASSED 2026-08-08: "Well it works, we are sliding. I cant detect any speed change from retail." Filed alongside: #347 + AD-70 (our glide alternates arm/move at half retail's per-tick rate — retail redirects within the tick; next up by user direction), AD-71 (the guard's mutable WalkableAllowance operand vs retail's fixed is_valid_walkable global — now return-value-bearing), and the reviewers' named residuals in the #345 closure entry (placement-arm flip, other-cell coverage gap, EdgeSlide-less projectiles, ACE's server-side shared misport predicting remote drift-then-snap on steep terrain). The unported IsViewer arm of validate_walkable is noted in the D0 doc. Suite: clean-room complete solution 11,271 passed / 4 skipped / 0 failed; Core assembly re-run green after the review-driven test hardening. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 13:32:51 +02:00
Erik	10efb5b1f9	fix(physics): AD-66 relands — the push-out uses retail's bare radius; plant-then-lift complete (#341 closed) ... Third attempt, landed on evidence where the first two correctly refused: the ten-run stability gate passed 10/10 bit-identical (0x42667451, two clean-room cycles among the runs), the recalibrated golden's every value measured with derivations rather than guessed, and the historical measurement flip stands recorded as unexplained-but-unreproducible after 37 hunt runs plus these 10 found no divergence anywhere. The mechanism, completing the S4b byte-pin: validate_walkable plants the sphere at perpendicular r*N.z (byte-faithful, untouched); this push fires once per settle and lifts to tangent equilibrium dist=r, where the trigger goes quiet — retail's slope hover, arriving via the push exactly as the original substitution's own comment predicted retail had. Sabotage: restoring radius*N.z reddens the discriminating exact-value test verbatim. AD-65 conformance, the uphill no-flap guard, and the #331 absorb pin all green untouched. AD-66 retired (the campaign's last withheld row); AD-69's seam-frame correction deliberately unbundled, stays active as its own follow-up. Clean-room suite 11,267 / 4 / 0 — the suite's two AD-66 skips are gone. User's "port the retail pair" decision is now fully executed; the hover-look slope gate is the remaining acceptance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 12:01:15 +02:00
Erik	e761761aa3	probe(physics): ACDREAM_DUMP_TRANSIT_FAIL — self-selecting transition-phase trace for #345 ... Fires only on the stuck-tick predicate (>=1mm XY requested, <=0.1mm achieved), buffering per-tick phase outcomes cheaply and flushing only on a stuck tick: per-insert-attempt phase/state/normal/source, step-up enter/exit verdicts, every ValidateWalkable branch with dist/waterDepth and both SetCollisionNormal guards evaluated, and the tick's final AdjustOffset pair. Zero cost when off (flag before any allocation — the I1 zero-alloc gate stays green), mover id on every line, [ThreadStatic] buffer per the referee-safety rule. Two tests: fires on a synthetic wall-stuck tick, silent on ordinary movement. Diagnostics only; no behavioral change. Suite 11,271 / 6 / 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 10:48:46 +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	c5443b3df9	test(physics): S6 — the camera provably reaches both PerfectClip TOI tails; contained, not dormant ... AP-83/AP-91 claimed no current mover sets PerfectClip. The containment proof found the opposite and the contract's honest-fallback fired: the camera probe (the sole production setter) reaches BOTH ACE-derived tails live — the viewer exemption is creature-only, the shadow-list walk is unconditional, and static scenery with authored primitives is a real non-creature population. Every reach is now recorded (camera-live silently; any non-viewer mover loudly, one-shot), so a future flag change cannot exercise unreviewed ACE-derived math silently. Four tests drive the camera's exact call shape both ways; the sabotage was intelligently adapted — there was no existing cut to disable, so it flips the one axis the proof depends on (IsCreature) and asserts reachability inverts. Both register rows rewritten CONTAINED-not-dormant with severity narrowed to camera-feel (the probe never commits a PhysicsBody). Landing note: diagnostics-only diff (two guard calls + counters + corrected stale comments), verified directly by the session lead rather than a review cycle — the review budget went where behaviour changed tonight. Campaign S CLOSES with this landing: S1A/S1B/S2/S4/S5/S6 done, S3 cancelled, three user-passed gates, one honestly-open item — AD-66's reland, twice self-refused by its own stability gate, blocked on the #341 codegen-shape measurement instability whose ABA evidence and first discriminating experiment are filed. Clean-room suite: 11,257 passed / 6 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 09:21:40 +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	b3e43d22c9	fix(physics): S1B — indoor cell membership admits on the part BOX, as retail does (#335, AP-159 narrowed) ... CellTransit.FindTransitCellsBox ports CEnvCell::find_transit_cells' part-array overload @0x0052cae0 line-for-line: per-portal x per-part order, the sphere cheap-reject at F_EPSILON+radius, the box admit whose "Straddle or crossing-side" rule is exactly retail's `eax != side` under the PDB Sidedness enum, leads-outside placed AFTER the admit, the unconditional unloaded-neighbour hint without the sphere overload's re-test, the destination box_intersects_cell gate with its deliberate no-break, and add_all_outside_cells after the loop. The box-vs-cell BSP traversal lands in BOTH representations behind the flat-authoritative dispatcher with a graph referee whose 20,000 installed comparisons are pinned by assertion (review F5), zero mismatch. Dual Opus review: PASS on both lenses. The mandatory D0 pseudocode pass caught that the contract's own supplementary note misattributed the box block to the sphere overload — it belongs to a SECOND check_building_transit overload @0x0052c680, whose portal-side convention is INVERTED and whose admit differs; the pseudocode doc now records that trap plus two byte confirmations made at review: which_side @0x00444720 is strictly > eps for POSITIVE, and intersect_box's in-plane early exit returns CROSSING(3) (jp @0x005aa1bc -> mov eax,3), settling review items b1/b2 for the future bridge porter. The bridge itself stays unported as AP-159's explicit remainder. The review also retired #335's severity premise honestly: "over- inclusive only, never a missed one" is wrong at production shape ratios, where the box (whole-vertex AABB) legitimately exceeds the sphere (physics-polygon root sphere). Measured, both populations: rigged (box << sphere) — 1,520 placements, 978 cells removed, 0 added; production-ratio (box >= sphere) — 950 placements, 20 removed, 1 ADDED through the loaded-neighbour gate, which is retail's direction, not a defect. The no-op guard (review F4) asserts removal is nonzero so an unwired admit cannot pass silently. Process note: the implementer authored against this session's worktree at bec5c69d, 25 commits stale — the recorded worktree-base class. All six files were byte-identical between bases, the diff transplanted losslessly, and every verdict-bearing run (referee, direction sweeps, this clean-room) was re-executed on current main. S2's uncommitted phase-1 edits were stashed for this landing so the suite verdicts exactly one changeset. Also untracks 341-slope-capture.jsonl (an accidental add) and gitignores it. Clean-room suite: 11,248 passed / 6 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 07:46:57 +02:00
Erik	d73125d3b0	fix(physics): S4/AD-65 — the away-from-plane response snaps to the surface, as retail does ... Campaign S slice S4, the half that landed. Retail's CTransition:: adjust_offset @0x0050a370 branches on dot(offset, contactPlane.N) at 0x0050a4fa: moving INTO the plane subtracts the normal component (0x0050a529), moving AWAY calls Plane::snap_to_plane @0x00509c50 — which preserves X and Y and re-solves ONLY Z so the offset lies in the plane (the d terms cancel algebraically), no-op under the 0.000199999995f |N.z| epsilon. acdream ran the orthogonal projection in BOTH directions, shrinking downhill XY travel by cos^2(theta): 25% at 30 degrees, 50% at 45 — AD-65's recorded shortfall, now retired. The combined Opus review independently re-derived the algebra, the branch polarity, the epsilon's bit-identity (17b75139), and the sabotage magnitude (the re-instated projection yields X = 0.75 = cos^2 30 exactly), and verified the delta is 4 non-comment lines with the into-plane arm, the crease arm, and both no-plane arms untouched. Its blast-radius sweep found the away arm exercised but NOT discriminated by any pre-existing test — every one asserts lower bounds the snap over-satisfies — so the two new exact-value tests are the only discriminating coverage, recorded in the test's class doc, and the felt 33-100% downhill speed-up is the morning gate's one row. AD-66 (the push-out's bare radius) is WITHHELD: byte-confirmed twice, implemented, then pulled after the same clean-room binaries measured contradictory absorbed-tick outcomes flipping with nothing but test assert shape — issue #341 carries the observation matrix and the apparatus plan; its two exact-value tests are [Skip]-ed; the retained substitution's rationale is restored at the site per review F1, with the review's remaining findings (F2/F3/F4/F5/F6) applied and F8 filed as #342. AD-69 filed: the same block omits retail's get_block_offset seam-frame correction, deferred to the AD-66 relanding for attributability. #340 filed: a fifth load-sensitive flake. Review verdict: PASS. AD-65 is provably unable to reach the #341 anomaly's code path (the absorb scenario takes the crease arm). Clean-room suite: 11,239 passed / 6 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 02:45:03 +02:00
Erik	55b07f6a62	refactor(physics): hoist the live-entity collision builder to Runtime (#330 groundwork) ... LiveEntityCollisionBuilder and LiveEntityDefaultPoseResolver move from AcDream.App.Physics to AcDream.Runtime.Physics with no behaviour change — diff-verified byte-identical shape math by both review lenses. The Build signature's App-record parameter is replaced by presentation-free primitives with identical guard semantics, INCLUDING the FinalPhysicsState read the contract had missed and the implementer surfaced rather than dropped. Visibility stays internal: Runtime's existing InternalsVisibleTo grants already cover every consumer, so the implementation's public widening is reverted per the architecture review's finding 11. The registration WIRING is deliberately WITHHELD. Both Opus lenses failed it, converging: a shadow registered at spawn freezes there (RuntimeRemotePhysicsUpdater is Runtime-homed but App-driven — nothing headless ticks it), so a walking NPC becomes a phantom obstacle at its spawn point while the real NPC still passes through the bot; three of five shadow-lifetime edges leaked (pickup leaves a permanent invisible collider, supersession orphans a duplicate, generation reset never unregisters and the K-ledger convergence oracle only checks retained shadows AFTER disposal clears them); and headless cannot resolve BSP collision assets at all, so doors and chests would still be walk-through. The frozen-shadow root was the SESSION LEAD's contract error (fact 3), not the implementer's. #330 stays OPEN, rewritten as the seven-point scope map the reviews produced — the honest overnight deliverable is that map, not a half-mechanism carrying new divergences. Suite 11,235 passed / 4 skipped / 0 failed (the withheld seam's two tests account for the delta from the implementation run's 11,237). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 01:49:13 +02:00
Erik	52aea775b9	test(physics): AP-157 measured — CylHeight half retired, sorting-sphere half proven collision-unreachable; AD-55 byte-decoded ... Campaign S S1A, both outcomes the measure-first rule exists for. AP-157's CylHeight half is RETIRED as a non-divergence: retail's own cylsphere overload (CObjCell::find_cell_list @0x0052b9f0) copies localtoglobal(low_pt) + radius per cylsphere, capped at 10, and never reads height — retail collapses a cylsphere to a base-point sphere exactly as acdream does. The sorting-sphere half measured REAL against retail's registration set — 1,812 of 3,343 evaluated Setups (54%) fail containment at 1 mm, worst shortfall 18.135 m — and then PROVEN collision-unreachable: for this branch the flood spheres and the collision-test geometry are the same per-part Sphere list, so every omitted cell is one the entity's test geometry cannot reach, and retail's wider sorting-sphere registrations are narrow-phase rejects on retail too. Fix deferred to the next bake-schema revision rather than performing Slice I3 surgery for zero behavioural delta. The measurement test stays in the tree as the permanent record (population cross-checked against the dispatch test's independently-committed constants: 3,506 = 3,605 - 99). AD-55 is byte-decoded and RESOLVED against our constant: the binary loads qword [0x007c6b28] = pi/18 exactly and executes FCOS — retail's Sledding flatness threshold is cos(10 deg) = 0.984808. Our 0.99999536f is cos(0.17453 DEGREES): the radian literal misread as degrees, which makes the object-friction arm unreachable on real terrain (nothing is flatter than 0.175 deg). Evidence note carries the full instruction listing and the polarity of the test ah,0x41 / jp idiom; the one-line fix + conformance test is S5, queued behind the running implementation slice for build-slot reasons. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 00:57:36 +02:00
Erik	332045c7ad	fix(physics): split set_contact_plane from init_contact_plane (#32 local edge-slide) ... Measured live at Rithwic 2026-08-06 with ACDREAM_DUMP_EDGE_SLIDE=1. Six branch2/steep-cliffslide events, every one reporting curN=(-0.954,0.000,0.301) lastN=(-0.954,0.000,0.301) angle=0.0000 apply=False, outcome degenerate-cross/last-known. That is decision-table row 1 of the research doc, verbatim. CTransition::cliff_slide @0x0050a6d0 takes its slide direction from cross(steep contact normal, last_known_contact_plane.N) — it needs the surface the mover was STANDING ON as the second vector. acdream's CollisionInfo.SetContactPlane latched the last-known group on every call, so by the time cliff_slide ran, last-known had already been overwritten with the steep face itself: the cross product of a vector with itself, which is zero. Degenerate direction, no slide, walk off the cliff. Retail's COLLISIONINFO::set_contact_plane @0x00509d80 is 22 bytes and writes the CONTACT group only; the last-known group has four writers, none of them that function. So the four writes are DELETED and a new InitContactPlane mirrors CTransition::init_contact_plane @0x0050e850, writing both — the start-of-transition seed, where there is no earlier surface to remember. Only check_contact's SUCCESS branch calls it. The other eleven call sites keep the narrowed setter. This is a port, not a suppression: no guard, no grace period, no flag. The user's own A/B was the discriminator: Neftet's block plateaus hold (188 branch3/precipice-slide events, all before the teleport) while Rithwic's terrain cliff fails (6 branch2 events, all after). I had predicted the opposite — that terrain would be the flat-normal case — and position plus timeline corrected me, not reasoning. NEW DISCRIMINATING TEST, because the suite had none. It was green both before and after the production change, so nothing in it defended this behaviour. Issue32LastKnownContactPlaneTests seeds a walkable plane, asserts a steep mid-transition contact leaves it intact, and asserts the resulting cross product is non-degenerate. Sabotage-verified: restore the four writes and both discriminating rows fail while the InitContactPlane control keeps passing — the pair separates 'the latch is gone' from 'nothing writes last-known at all'. Two existing tests corrected rather than deleted. PhysicsSetPositionTests.FailedCheck_MapsCollisionHandlerResultToRetailError passed BECAUSE of the latch (the file the research named); its hook now populates both groups explicitly, since it asserts report plumbing, not setter semantics. RetailEdgeResponseOrderingTests.TransitionalInsert_ DegenerateCliffSlideOk_ContinuesOuterRetry was predicted to fail and did not — it now passes for a DIFFERENT reason (last-known absent rather than clobbered, which retail also answers with OK_TS). Its comment described the deleted behaviour and is corrected to say so, and to say it does not discriminate this fix. Also repairs the #338 probe. Its first placement in PlayerMovementController printed nothing across 11,523 live log lines — the wrong one of two resolve call sites — so it moves to PhysicsEngine.ResolveWithTransition where every caller passes through, filtered to the player. The dead site is removed rather than left in place; a probe that never fires is worse than none. The flag test now precedes the interpolated string: building it eagerly cost 128 B per resolve with the probe OFF, which Slice I1's zero-allocation gate caught. Suite 11,234 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 00:15:24 +02:00
Erik	ea83b043df	fix(physics): delete the query-site broadphase reach filter (#333, closing #337) ... Transition.FindObjCollisionsInCell discarded a shadow candidate when |currPos - obj.Position| > sphereRadius + obj.Radius + movement.Length() + 2f obj.Position is the part ORIGIN; obj.Radius is the physics-BSP ROOT BOUNDING SPHERE's radius, measured about a centre AP-156 established is frequently metres from that origin (376 of 973 installed physics-BSP parts sit further from their part origin than half their own radius, worst 20.762 m). Geometry deep inside the real bounding sphere was therefore thrown away before BSPQuery ever ran: solid near the origin, permeable in a bounded shell beyond it. For the Neftet rock 0xC8766009 / gfx=0x01004751 the two points are 23.556 m apart, which is #337 — wedged on the plateau, jumps sinking into the mesh, corpses falling through. A live capture recorded 7,225 rejections on that one owner, every single one with wouldAcceptAtCenter=True. Deleted rather than re-centred. Retail has no distance pre-filter, disassembled from the PDB-paired v11.4186 binary (CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32) rather than read from Binary Ninja: CObjCell::find_obj_collisions @0x0052b750 walks shadow_object_list and calls CPhysicsObj::FindObjCollisions (0x0052b78b) UNCONDITIONALLY; its only early-out is insert_type == INITIAL_PLACEMENT_INSERT (0x0052b759). CPhysicsObj::FindObjCollisions @0x0050f050 contains no float compare at all. CPartArray::FindObjCollisions @0x00518180 is a bare do/while over parts, and CPhysicsPart::find_obj_collisions @0x0050d8d0 is two null checks plus a call. Retail's only spatial rejection is the BSP node bounding-sphere test inside the walk — correctly centred, which is exactly what the deleted filter was not. Re-centring it (carry BoundsCenter on ShadowEntry) would have preserved an invention retail does not have, including a +2f slack and a movement.Length() term with no retail counterpart, and left a second reach budget to be tuned forever. Retail's own cross-cell slack constant is F_EPSILON = 0.0002 m, not 2 m. The method's comment claimed the filter was "the analog of the part sorting-sphere early-outs inside retail's CPhysicsObj::FindObjCollisions — response-neutral, pure perf". Both halves were false and cost #333 and #337; it is replaced by the disassembly above. Gate: Issue333BroadphaseReachFilterTests drives the production path end-to-end (ResolveWithTransition -> FindObjCollisionsInCell -> CollisionTraversal) on a DAT-free fixture so it runs everywhere, as a discriminating pair. Sabotage-verified: restore the pre-check and OffCentreBspFloorStopsAFallingMover reaches z=37.800 — exactly the unobstructed fall, blockedAtLeastOnce=False — while CentredBspFloorStopsAFallingMover keeps passing. Without the control a fixture unable to fall would pass the first test for the wrong reason. Issue337's skipped TheBroadphaseAdmitsTheSurfaceTheMoverIsStandingOn asserted the now-deleted predicate and could never have gone green; it is rewritten as installed-DAT evidence pinning BOTH halves of the diagnosis and is no longer skipped. Perf measured, not assumed (Release, synthetic all-BSP cell, per ResolveWithTransition): at 38 candidates — the live maximum — 10.61 us -> 16.68 us (1.57x); at a deliberately unreachable 200, 17.34 -> 39.48 us (2.28x); ~0.16 us per additional candidate tested. Over 19,701 live [reach-q] samples the in-cell count is p50 = 9, p99 = 32, max 38. The ACDREAM_PROBE_REACH rejectedReach column is kept and is now structurally 0, so a post-fix capture stays comparable with the pre-fix one; dropping it would make the two incomparable. AP-158 retired (110 active AP rows). #333 and #337 closed pending the user's live acceptance at Neftet. Solution suite 11,231 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 22:16:53 +02:00
Erik	5a1eeace73	docs(physics): #337 diagnosed — it is #333's query-site broadphase, not the mesh ... Report-only. No production code changed. The collision mesh is present, correctly shaped, correctly placed in the world, and the BSP traversal reaches every part of it. The mover never gets as far as the query. FindObjCollisionsInCell's per-object broadphase measures the mover's distance to the shadow entry's Position — the part ORIGIN — and compares it against obj.Radius, which is the physics-BSP ROOT BOUNDING SPHERE's radius. For 0xC8766009 those two points are 23.556 m apart, so a mover standing on its plateau is inside the real bounding sphere by ~20 m of margin and is still rejected. Same defect AP-156 fixed in the flood and #334 fixed in the registration extent walk, left in place at the query site. Measured, not inferred. An offline replay against the installed DAT reconstructs all eleven landblock-0x8766 owners and matches the live [geom] placement exactly (0xC8766002 at (84.699,100.082,13.000) yaw -45.00 vs the log's objPos + bspCentreOffset). At the position the client fell through, the production swept query returns a hit on poly 31 at 0.037-0.366 m while the filter rejects the candidate: distToOrigin=60.434 > maxReach=59.697, distance to the bounding-sphere CENTRE 37.083 m against a 56.909 m radius. The live capture recorded that rejection 7,225 times with the probe's own wouldAcceptAtCenter=True on every one. Bounded because the dead zone is the shell between maxReach and the true sphere, up to ~23.5 m thick on the far side. movement.Length() is a budget term: a 0.25 m walking step gives shortfall +0.60, a 0.72 m step +0.14, and ~0.86 m passes — which is exactly why jumping over the spot works, walking into it does not, and a corpse falls through. Three hypotheses refuted by measurement, not by argument: - "the rock's own mesh never collides" — true of 0xC8766002 and it is INNOCENT; its geometry is 22.8 m from the wedge and it has zero brute-force hits over a 12,493-point lattice covering the plateau. It is a candidate only because it is a 130x147 m owner. The rock actually walked on is 0xC8766009. - wrong world transform — the offline placement reproduces the runtime exactly, and a uniform displacement cannot produce a bounded pocket. - BSP traversal hole — a referee ran the production walk against brute force at 7,770 on-surface probes across all eleven owners plus 137,423 lattice points. Mismatch 0 everywhere. A 0.5 m hole map also shows continuous upward-facing coverage across the whole wedge region. [geom]'s verdict=coincident was never able to decide this: LogGeometry compares the physics box against the visual box in the object's OWN LOCAL FRAME, so it proves shape agreement and says nothing about world placement. Recorded in the doc so the next reader does not re-trust it. Retail has no per-object distance filter on the BSP branch. Verified instruction-by-instruction with cdb against the PDB-paired v11.4186 binary: CPartArray::FindObjCollisions @0x00518180 is 14 instructions of bare do/while over parts[i]; CPhysicsPart::find_obj_collisions @0x0050d8d0 is 17 instructions of two null checks plus the call to CGfxObj::find_obj_collisions @0x00534700. No compare, no float math in either. The in-tree comment calling the filter a retail analog and response-neutral is wrong on both counts. The support=object cpNz=1.0000 readings inside the rock are not the rock: ValidateTransition:6076 is retail's stationary-fall failsafe manufacturing a flat plane through the sphere bottom, and :5997 is the LastKnownContactPlane restore holding a stale plane. Both are retail-correct responses to a stuck body, and they are why the client believes it is standing while ACE rejects the position. Preferred fix is to delete the pre-check for BSP entries and correct the comment; fallback is to measure to the bounding-sphere centre, which also needs BoundsCenter carried on ShadowEntry. Neither is landed. The reproducer was confirmed to FAIL when un-skipped, with the numbers above — this campaign has caught eleven green tests covering nothing, so a fixture that cannot distinguish the bug is worse than none. Gates: bin/obj deleted, Release build 0 errors, Core suite 4,287 passed / 2 skipped / 0 failed (baseline 4,286/1 plus three new dumps and the one deliberately skipped reproducer). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 21:16:31 +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	4abd1b5eb7	fix(physics): AP-152 — dispatch collision shapes BSP-first, at emission and at the cell flood ... The register row predicted "catching or stopping on a doorway sill". That symptom could not have been occurring. `Transition.BspOnlyDispatch` (TransitionTypes.cs:1348, landed 2026-05-25 as A6.P7) already skipped both primitive branches (:3911, :3954) whenever the target's wire PhysicsState carries HAS_PHYSICS_BSP_PS, and ACE sets that bit from CSetup.HasPhysicsBSP for every affected Setup. The extra primitive was never tested for collision. The live defect was CELL MEMBERSHIP. The same shape list feeds `ShadowObjectRegistry.BuildFloodSpheres`, which had no such guard and preferred Cylinders over everything whenever any Cylinder existed — retail's SECOND priority applied ahead of its first. For the 73 CylSphere+BSP Setups acdream therefore flooded shadow cells from the cylinder and never from the slab: an object absent from cells it physically occupies, which is the #98 / #168 symptom class, not the door-collision class the row named. Retail, re-disassembled from the PDB-paired binary (v11.4186, CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32, check_exe_pdb.py MATCH) rather than taken from Binary Ninja, which drops flag tests: CPhysicsObj::FindObjCollisions @0x0050f050 0x0050f165 test dword [esi+0xa8], 0x10000 0x0050f16f je 0x50f1a2 ; clear -> primitive dispatch 0x0050f18d call 0x518180 ; CPartArray::FindObjCollisions 0x0050f19d jmp 0x50f2b0 ; UNCONDITIONAL, past BOTH primitive loops ; (CylSphere 0x50f1a2, Sphere 0x50f21d) 0x0050f1d6 jae 0x50f317 ; CylSphere loop exhausted -> RETURN 0x0050f22f je 0x50f31b ; zero Spheres -> RETURN seeded OK_TS CPhysicsObj::calc_cross_cells @0x00515230 0x00515285 test dword [esi+0xa8], 0x10000 0x0051528f jne 0x515305 -> CPhysicsObj::find_bbox_cell_list @0x00510fc0 0x005152d1 call 0x52b9f0 ; cylsphere branch, below the jump 0x005152fb call 0x52b990 ; sorting-sphere branch, below the jump Priority at both consumers: BSP -> CylSphere -> Sphere -> nothing. BSP wins. Every address above was resolved back to its symbol by exact lookup in named-retail/symbols.json. Changes: * `ShadowShapeBuilder.FromSetup` gains a step-0 dispatch gate. Steps 1 and 2 are skipped entirely when any part's EFFECTIVE GfxObj carries a physics BSP. The gate and step 3 now share one `EffectivePartGfxObjId` helper, so they cannot read different identities — a gate on `setup.Parts` would, after an ObjDesc swap, suppress the primitives while step 3 emitted nothing and `Build` returned null, deleting the entity's collision. Emission order is unchanged. This also removes acdream's undeclared reliance on the server sending the flag: the gate is derived from the parts, exactly as CPartArray::CacheHasPhysicsBSP @0x00518110 derives it. * `ShadowObjectRegistry.BuildFloodSpheres` now applies calc_cross_cells' own order: BSP, else Cylinder, else everything. Given the gate above this is a no-op for every shape list acdream produces (FromSetup is now exclusive; both landblock-static publishers already emit homogeneous lists), so the measured membership delta remains attributable to the gate alone. It is kept for the same reason BspOnlyDispatch is kept: retail genuinely dispatches here, and it guards a future additive producer. `Transition.BspOnlyDispatch` is deliberately untouched. Register: AP-152 RETIRED with its four false statements corrected — the risk statement (the symptom was already inert); "small and centred at the part origin" (max primitive is 6.714 m, and 0x0200086E's sphere origin is (0.759, 0.165, 5.842)); the cottage door's "~14 cm base Sphere" (it is 0.100 m; 0.141 is Setup.Radius, which AP-22 proved is never collision geometry); and naming one pinning test where two existed. AP-153/154/155 filed: retail's dispatch flag is cached once at InitPartArrayObject+0x7e where acdream's gate is live; the query-time guard takes a client-derived flag off the wire; and the static publishers emit Setup Spheres as height-capped Cylinders while BuildFloodSpheres approximates retail's bounding box with bounding spheres. Tests. Both pinning tests corrected, neither deleted: `FromSetup_DoorSetup_ProducesFourShapes` -> `..._EmitsBspPartsOnly`; `FromSetup_DoorSetup_SphereAtExpectedLocalOffset` re-hosted on `_ => false`, the DAT-real configuration for the 3,605 Sphere-only Setups. `FromSetup_ScaleFactor_MultipliesAllRadiiAndOffsets` was the campaign's eighth green test covering nothing — its assertions sat inside `if (CollisionType == Cylinder)` on a fixture with zero CylSpheres, so only `Scale == 2.0f` ever ran. Proved empirically: with the sphere radius scale deleted, the old body passes and the corrected body fails. Three new facts: the effective-identity gate, the App-layer CylSphere+BSP registration (no App fixture combined the two before), and the flood-set dispatch. One new installed-DAT sweep pins 172 affected Setups (73 CylSphere+BSP, 99 Sphere+BSP) behind external bucket controls, re-measured independently and agreeing exactly with the filing commit's separate sweep. All eight sabotages run and reported; every discriminating fact reddens in the intended direction and only there. Clean Release build after deleting every bin/obj: 0 errors. Complete suite 11,203 passed / 4 skipped / 0 failed, +5 on the 11,198 baseline at ec29a732 — exactly the five added facts, no new skips. Blast radius, corrected: the FromSetup half is graphical-only (its sole production caller is LiveEntityCollisionBuilder in AcDream.App, which AcDream.Headless cannot reference — Headless -> Runtime -> Core/Content). The BuildFloodSpheres half lives in AcDream.Core and DOES execute in Headless via LandblockPhysicsContentBuilder, but is behaviour-neutral there because both of that builder's registrations pass homogeneous lists. Headless suite green at 89/89. NOT yet gated live: this changes shadow-cell membership for 22 Setups used by 151 Door weenies and 38 stationary props. Needs a connected session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 14:51:36 +02:00
Erik	ec29a732f5	test(physics): settle #331 — the uphill "refusal" is the #137 anti-parallel absorb, not a defect ... #331 reported that `PhysicsEngine.ResolveWithTransition` refuses ALL uphill motion whenever a `body:` is supplied. It does not. It refuses a step whose sub-step offset is exactly anti-parallel to a live sliding normal — the #137-family absorb this project already recorded as retail-faithful. Measured on the same fixture, same gradient, same body, varying only the heading relative to the slope gradient: (0, -0.1, 0) cross-slope 0 -> zero movement, latched (0.0001,-0.1, 0) cross-slope 0.0001 m -> zero movement, latched (0.001, -0.1, 0) cross-slope 0.001 m -> climbs 0.176 m in 5 ticks (0.01, -0.1, 0) cross-slope 0.01 m -> climbs 0.176 m in 5 ticks The threshold is retail's own F_EPSILON small-offset abort (0.0002 m): about 0.11 degrees off the exact gradient at a 0.1 m step. `RemoteRampHarness` builds a ramp whose gradient is exactly along Y and the original probe pushed exactly along -Y, so it hit the measure-zero case with probability 1. The latch itself is production-real in mechanism — a pure gravity fall under the production RuntimeRemotePhysicsUpdater, with no fixture settle seam involved, lands leaving Contact|OnWalkable|Sliding with slidingNormal (0,1,0) — but every link is faithful to retail, verified in the PDB-paired binary rather than Binary Ninja (BN typed find_transitional_position `void` and dropped the load-bearing return value): validate_walkable sets collision_normal from the terrain plane when OBJECTINFO CONTACT is clear 0x0050d251 / 0x0050d261 / 0x0050d26c validate_transition converts it unconditionally 0x0050ac19-0x0050ac30 set_sliding_normal zeroes Z AND re-normalizes 0x0050a060 SetPositionInternal persists SLIDING_TS 0x005154c2 / 0x005154e1 get_object_info re-seeds it next frame 0x00511d44 / 0x00511d4f find_transitional_position returns `i != 0 && state == OK` on the step-0 abort 0x0050c0ed -> 0x0050c089 ACE agrees (Transition.cs:1027, CollisionInfo.cs:58). No production code changed; no divergence introduced, so no register row. What lands is the coverage whose absence made this invisible — nothing in the suite asserted that a body-bearing mover makes uphill progress on a walkable slope, and the test that found #331 passed vacuously because the body never moved: RuntimeRemoteUphillProgressTests.ARemoteWithABodyClimbsAWalkableSlopeAndKeepsItsFeetOnIt per-tick climb + surface tracking under a realistic off-gradient heading. SAB-A1 AdjustOffset -> Vector3.Zero reddens at tick 1 SAB-A2 fixture gradient -> 0 (flat) reddens at tick 1 RuntimeRemoteUphillProgressTests.AnExactlyUpSlopeOffsetIsAbsorbedByThePersistedSlidingNormal characterization pin for the absorb, with the retail anchors inline. SAB-B1 delete the get_object_info sliding seed reddens (climbs to 57.7544) SAB-A1 reddens SAB-A2 reddens NON-discriminating, measured and documented: making the final tick exactly up-slope leaves it green — by then the latch is already cleared. RemoteRampHarness gains a warning block naming the axis-alignment trap so the next vacuous uphill assertion is caught at authoring time. Suite re-measured from a full clean (43 bin/obj removed): 11,198 passed / 4 skipped / 0 failed, against the 11,196/4/0 baseline at 0d62a5ff — exactly the two tests added. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 14:08:22 +02:00
Erik	886333a2a9	refactor(physics): delete the redundant pre-sweep slope projection (AD-10 retired) ... Stage 0's measurement (previous commit) says the projection is redundant, so AD-10 retires by deletion rather than by narrowing. The measurement. With the sample forced to null at BOTH fork sites, from a clean build: * a remote running 30 ticks down a 31-degree walkable ramp produces a BIT-IDENTICAL trajectory, position for position; * on an 8.4-degree ramp the two differ by at most 2.8e-5 m in Z after 30 ticks (0.03 mm) and are identical in X and Y — float ordering noise from projecting twice against the same plane rather than once; * the whole AcDream.Runtime.Tests suite is unchanged. That is what redundancy looks like, and the arithmetic explains it. The boundary projection and Transition.AdjustOffset are the same operation (v -= N * dot(v, N)) against the same plane, and the composition is idempotent: a vector already on the plane has dot(v, N) == 0, so the sweep's own projection is a no-op on an already-projected offset and the full-strength projection on an unprojected one. Either alone produces the same offset. On terrain a THIRD mechanism, ValidateWalkable's push-out, re-seats the sphere on the plane every sub-step regardless. Deleted: * both RuntimeRemotePhysicsUpdater sample sites (the host and no-host fork branches carried the block verbatim — the AP-22 shape, a row naming one site where two exist); * the terrainNormal parameter and projection block on RemoteMotionCombiner.ComposeOffset; * the same block on ComputeOffset, which has no production callers but held a second copy of the divergence, so leaving it would have made the row's retirement false; * PhysicsEngine.SampleTerrainNormal, now callerless. Removing the parameter rather than passing null is deliberate: it is what makes a future one-site-only regression a compile error instead of a silent half-fix. Two tests went with it — ComputeOffset_RootMotionFallback_SlopedTerrainNormal_ProjectsZOntoSlope and its flat-ground twin. Both were weak on their own terms: they drove the production-dead ComputeOffset and computed their expected values by re-implementing the projection formula, so they could catch a wrong MULTIPLY but never a wrong PLANE — which is exactly what the divergence was. The surviving coverage is geometric and runs the production tick. Three claims in the old row did not survive contact with the code and are recorded in the retired row rather than quietly dropped: the justification (remotes do run the sweep); the description of ComposeOffset's guard as "interpolation-active" when the code reads `if (!interpolationOverwrote`; and the roof clause, stale since Bug B gated the sample on OnWalkable — a steep roof is OnWalkable == false, so the path never ran on #32's geometry. The retail anchor is corrected too: pc:272296-272346 truncated both the sliding-normal validity gate at the head and the entire safety push-out block at the tail. The whole function is 0x0050a370, pc:272271-272393. This does not fix #32 and does not partially fix it. #32's remote half was already closed at 204d0ae0. What deletion does improve is the case #32 never covered: a remote on a WALKABLE non-terrain surface — a bridge, a dock, a gentle roof, a ramp inside a building — where the terrain sample returned the plane of the ground far below and applied a wrong plane rather than none. That surface now gets the body's own committed contact plane, because that is the only projection left. The planning contract this work executed is committed alongside as docs/research/2026-08-06-ad10-contract.md. Release build 0 errors. Complete solution suite 11,196 passed / 4 skipped / 0 failed against the ef976c6d baseline of 11,195 / 4 / 0 — reconciled exactly as +3 new Runtime tests and -2 deleted Core tests. Visual gate outstanding: G1 (the ~5 Hz staircase on rolling terrain) is the veto criterion and runs first; then slope-descent smoothness, a walkable non-terrain surface, the #32 roof scenario, and flat ground. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 09:35:22 +02:00
Erik	fe6ee877d1	test(physics): measure whether the remote sweep alone tracks surface Z (AD-10 Stage 0) ... AD-10 claims the remote slope projection is "relocated" out of the sweep because "remote bodies don't run a full local transition sweep". That justification is false at HEAD: RuntimeRemotePhysicsUpdater.Tick calls PhysicsEngine.ResolveWithTransition with the remote's own body, and that sweep runs acdream's verbatim port of CTransition::adjust_offset (0x0050a370, pc:272271-272393) once per sub-step. So the boundary projection is an EXTRA layer, not a relocation — and whether it is doing anything the sweep does not is a measurement, never an argument. This commit builds the fixture for that measurement and changes no production code. RuntimeRemoteSteepContactSlideTests' private Harness is extracted to RemoteRampHarness so the new tests share it instead of cloning ~180 lines. The extraction is behaviour-preserving; its only additions are the fixture's own TerrainSurface (so an assertion about "is the body on the surface" is answered by the surface geometry rather than by re-implementing what the code under test computed), a SurfaceZ helper, and a Tick overload that supplies a per-frame body-local root displacement — the locomotion-cycle push a running remote actually carries. All ten Bug B tests pass unchanged against it. RuntimeRemoteSlopeProjectionTests then drives the production tick 30 ticks down a 31-degree walkable ramp and asserts, on EVERY tick rather than at the end, that the body's root stays within 5 mm of its settled offset from the terrain beneath it. A staircase catching up on the final tick would pass a start/end comparison; 30 unprojected ticks accumulate ~1.8 m. Sabotage results, all from clean builds (bin/obj deleted), reported in both directions: * Discard the sweep's answer (Body.Position = postIntegratePos instead of resolveResult.Position): RED at tick 1, body 0.05999 m off the surface. This is the tracking test's discriminating sabotage. * Flatten the ramp to gradient 0: RED on the anti-vacuity guard (dz = 0.0000 m). That guard exists because the tracking assertion passes trivially on flat ground, where Z never has to move. * Short-circuit Transition.AdjustOffset to `return offset;`: GREEN. Recorded, not hidden — it is the reason the contract's proposed T1 sabotage was rejected. On terrain the sweep has a SECOND independent way to plant Z: ValidateWalkable's push-out re-seats the sphere at its natural resting distance from the terrain plane every sub-step. Removing the step-down probe as well does not change it either (measured). The tests therefore assert the OUTCOME the projection exists for, and say in their own doc comments that they are not unit tests of adjust_offset and must not be cited as such. One test the contract asked for is deliberately absent. An uphill counterpart was written, passed, and was then found VACUOUS: on this fixture ResolveWithTransition returns ok=False for uphill motion and the body does not move at all, so it "tracked the surface" by standing still. That finding is filed separately rather than shipped as a green test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 09:34:56 +02:00
Erik	619de97ad1	fix(test): evaluate BOTH deleted guards; correct AP-22's overstated coverage claim ... From the AP-22 dual review (both lenses PASS). No production change. THE RECORD WAS WRONG. bc4679cd claimed "Headless.Tests 89/89 exercises the site-3 copy". The architecture review disproved it by sabotage: restoring the invented cylinder in BOTH static sites left the entire suite green. No test anywhere references PublishStaticCollision, and the headless suite's dummy DAT proxy makes LandblockLoader.Load fail for every landblock, so CreatePublication returns before reaching it. Two of the three deletions — including the headless-only one — are pinned by the installed-DAT reachability proof ALONE. The deletion is still correct; the evidence claim was not, and a successor trusting it would think those sites had regression cover they do not have. THE TEST NOW COVERS WHAT IT CLAIMED. Its comment said "the exact guard the three deleted copies used", but site 1 guarded on `Radius > 0.0001f` while sites 2 and 3 used the strictly wider `Radius > 0f`. Those are not the same predicate: the review measured that they differ over the installed DAT by exactly one Setup, 0x02001657, whose radius is the denormal 1.3e-39. The test now evaluates BOTH and asserts each is empty, so the wider guard the headless-reachable deletion actually used is no longer asserted by proxy. Sabotage-verified: widening the new guard to `>= 0f` reddens it (1,652 zero-radius Setups appear), so the assertion is live rather than vacuously empty over real DAT data. AP-22's row also corrected for two precisions the reviews surfaced: the load-bearing fact is that all 1,652 no-primitive Setups carry Radius exactly 0 (not the 1,294 first cited), and retail's `report_object_collision` DOES read GetHeight for the quadrant field — recorded so a future reader does not mistake it for a refutation of "never collision geometry", which is a claim about FindObjCollisions' shape dispatch only. Reachability now independently reproduced by four decoders — the contract's sweep, the implementer's parser, and both reviewers' from-scratch parsers — plus tools/SetupInspect agreeing bit-for-bit on the cited ids. Content.Tests 125/125. No new skips; #302/#308/#321 did not fire. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 08:54:31 +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	bcb66ccdf3	fix(test): cover the atlas-tier seam the D-1 fix depends on; correct AP-150's citation ... Both items come from the D-1 fix review (both lenses PASS, D-1 genuinely closed). No production behaviour changes. L1 — THE SEAM HAD NO COVERAGE. The D-1 fix's "empty by construction" claim rests on LandblockSpawnAdapter's atlas-tier filter (`if (entity.ServerGuid != 0) continue;`) skipping the live server projections DetachNearLayer deliberately RETAINS across a demote. The reviewer removed that filter and all 4,170 App tests passed — only two Core unit tests caught it, none through a demote. So the invariant the re-assert depends on could have been deleted silently, re-opening D-1 by another route: a non-empty re-assert whose mesh reference is never satisfied leaves IsRenderReady false, which is the portal hang again. NearToFarDemote_WithALiveServerEntity_StaysRenderReady now demotes a landblock that CARRIES a live server-spawned entity through the real GpuWorldState + LandblockSpawnAdapter + LandblockPresentationPipeline, and asserts the retained entity never enters the desired set. Sabotage-verified: with the filter removed, exactly one test fails — this one — and the other 25 pass, including all four D-1 regression tests. That is the finding restated as a measurement: the D-1 tests genuinely do not cover this seam, and now something does. AP-150 citation corrected: the row cited 0x004D7064 as the ECM_UI::SendNotice_DisplayStringInfo call site. That address is the PStringBase construction of the "In Portal Space - Please Wait..." literal (:219516); the actual call is 0x004D70A1 (-> 0x006925B0). Same class of slip the #280 commit had just corrected for #326 — worth noting that a row filed WITH a byte-level disassembly still mis-cited a neighbouring address. Also refactored the existing pipeline demote test to keep its doc comment attached to its own method (an earlier insertion had orphaned its [Fact]). App.Tests 4,170 -> 4,171 passed / 3 skipped, net +1 for the new test. No new skips; none of #302/#308/#321 surfaced. src/ is byte-unchanged (the sabotage was reverted and verified). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 07:54:03 +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