diff --git a/docs/architecture/retail-divergence-register.md b/docs/architecture/retail-divergence-register.md index d9fcca7d..aee27523 100644 --- a/docs/architecture/retail-divergence-register.md +++ b/docs/architecture/retail-divergence-register.md @@ -62,14 +62,13 @@ accepted-divergence entries (#96, #49, #50). --- -## 2. Adaptation (AD) — 49 rows (AD-57/AD-58 filed 2026-07-30 at Campaign P P7 — re-argued from TS-24/TS-40) (AD-56 filed 2026-07-30 at the Campaign P final physics slice, split out of the retired TS-4 row — the narrow pure-vertical (zero horizontal velocity) steep-roof-landing freeze, confirmed retail-identical; AD-55 retired the same slice — the cos(10°) sled-flatness constant, byte-proven against `0x0050ee70`; AD-25 retired 2026-07-30 at Campaign P Slice P3 — the remote dead-reckoning post-resolve now calls the exact ported `PhysicsObjUpdate.HandleAllCollisions` (the same function the local player and every ordinary body already use) instead of its own hand-inlined, narrower reflect gate; the row's own premise ("the remote DR sweep hasn't been rebuilt yet") no longer holds; AD-53/AD-54 filed the same slice, split out of the retired TS-1 row — CliffSlide's three-source reference-normal fallback chain and the walkable-steepness reroute to CliffSlide; AD-52 filed 2026-07-29 at Campaign N slice N6 — the fragment-assembler 60 s partial TTL + completed-sequence ring; AD-51 filed 2026-07-29 at Campaign N slice N4 — the reclaimed-word pool for ACE's fresh-sequence cleartext RejectRetransmit; AD-50 filed 2026-07-29 at Campaign N slice N2 — the inbound-watermark ACE init; AD-49 stays reserved for Campaign N §5's blob-layer ordering deferral, filed when its slice lands; AD-47 and AD-48 filed 2026-07-29 at Campaign V slice V11 — the MSAA sample-position and present-pacing rows the campaign's risk register scheduled for the GL deletion; AD-11 retired 2026-07-23 — exact low-bit ItemUses predicate; AD-31 retired 2026-07-15 — the DAT-authored portal-space viewport replaces the black transit cover) +## 2. Adaptation (AD) — 46 rows (AD-25 retired 2026-07-30 at Campaign P Slice P3 — the remote dead-reckoning post-resolve now calls the exact ported `PhysicsObjUpdate.HandleAllCollisions` (the same function the local player and every ordinary body already use) instead of its own hand-inlined, narrower reflect gate; the row's own premise ("the remote DR sweep hasn't been rebuilt yet") no longer holds; AD-55 filed 2026-07-30 at Campaign P Slice P2, split out of the retired AP-7 row — the open cos(10°)-vs-0.99999536f Sledding slope-flatness constant; AD-53/AD-54 filed the same slice, split out of the retired TS-1 row — CliffSlide's three-source reference-normal fallback chain and the walkable-steepness reroute to CliffSlide; AD-52 filed 2026-07-29 at Campaign N slice N6 — the fragment-assembler 60 s partial TTL + completed-sequence ring; AD-51 filed 2026-07-29 at Campaign N slice N4 — the reclaimed-word pool for ACE's fresh-sequence cleartext RejectRetransmit; AD-50 filed 2026-07-29 at Campaign N slice N2 — the inbound-watermark ACE init; AD-49 stays reserved for Campaign N §5's blob-layer ordering deferral, filed when its slice lands; AD-47 and AD-48 filed 2026-07-29 at Campaign V slice V11 — the MSAA sample-position and present-pacing rows the campaign's risk register scheduled for the GL deletion; AD-11 retired 2026-07-23 — exact low-bit ItemUses predicate; AD-31 retired 2026-07-15 — the DAT-authored portal-space viewport replaces the black transit cover) | # | Divergence | Where (file:line) | Why it is safe / justified | Risk if assumption breaks | Retail oracle | |---|---|---|---|---|---| | AD-53 | `Transition.CliffSlide`'s reference-normal cross-product operand tries THREE sources in priority order (`LastWalkablePlane` if `Normal.Z >= FloorZ`, then `LastKnownContactPlane` at the same threshold, then world-up `UnitZ`); retail's `CTransition::cliff_slide` uses `this->collision_info.last_known_contact_plane.N` directly, with no fallback chain | `src/AcDream.Core/Physics/TransitionTypes.cs` (`CliffSlide`, the `referenceNormal`/`refSource` selection above the cross-product) | Filed 2026-07-30 splitting TS-1's retirement (Campaign P Slice P2). A fresh read of `last_known_contact_plane`'s own maintenance (pc:272659-272668) confirms retail overwrites it unconditionally from `contact_plane` every `validate_transition` pass — including with a steep plane — so retail keeps NO separately-preserved flat-ground history there either; this fallback chain is a genuine acdream invention, not a retail-matching read. Kept because it compensates for AP-4's incomplete `OnWalkable` bookkeeping (L.4-cliffslide-fallback, 2026-04-30): without it, `cross(currentSteep, lastKnownSteep)` degenerates to zero after >1 frame on a continuous steep slope, and CliffSlide returns `OK` (no deflection) instead of downhill drift — the "stay on the roof" wedge the L.4 session fought | If AP-4's `OnWalkable` reordering is ever completed/removed, `last_known_contact_plane` should carry the same information retail's does and this fallback chain becomes unneeded ballast (or, worse, silently picks a stale `LastWalkablePlane` over the now-correct current one) — re-audit together with AP-4 | `CTransition::cliff_slide` pc:272397 (0050a6d0); `last_known_contact_plane` maintenance pc:272659-272668 (~0050ad07); `docs/research/2026-07-30-response-layer-edge-family-pseudocode.md` §2 gap #2 | | AD-54 | `Transition.EdgeSlideAfterStepDownFailed` reroutes to `CliffSlide` instead of `PrecipiceSlide` when the stored walkable polygon itself is steeper than `FloorZ` (`sp.WalkablePlane.Normal.Z < PhysicsGlobals.FloorZ`); retail's raw `SPHEREPATH::edge_slide` has no steepness branch here — `if (walkable != null) { ... precipice_slide(...) }` unconditionally | `src/AcDream.Core/Physics/TransitionTypes.cs` (`EdgeSlideAfterStepDownFailed`, the `L.4-walkable-steep` block) | Filed 2026-07-30 splitting TS-1's retirement (Campaign P Slice P2). The permissive `LandingZ` walkable-acceptance threshold that lets a steep roof become "walkable" in the first place IS confirmed retail-faithful (`BSPTREE::find_collisions` unconditional `walkable_allowance = LandingZ`, pc:323740-323783, TS-4's own citation) — so a steep-roof walkable polygon is a real state retail also reaches. What is NOT independently verified is whether retail's outer `transitional_insert` caller absorbs a same-polygon-standing `COLLIDED_TS` from `precipice_slide` (its raw `find_crossed_edge` returning false while standing on, not crossing, the polygon) some other way that avoids the acdream "stuck in a Collided revert loop" this reroute prevents | If retail's outer retry loop turns out to already handle the no-crossed-edge-while-standing-on-a-steep-poly case without a reroute, this branch is an unnecessary compensating layer that could route a genuinely PrecipiceSlide-bound case (a shallow polygon edge that happens to sit at exactly `FloorZ`) into CliffSlide instead | `SPHEREPATH::edge_slide` pc:273001-273090 (0050b3d0, direct walkable branch quoted at pc:364-370 in the P2 research doc); `BSPTREE::find_collisions` pc:323740-323783 (0053a730, unconditional `LandingZ`); `docs/research/2026-07-30-response-layer-edge-family-pseudocode.md` §2 gap #3 | -| ~~AD-55~~ | **RETIRED 2026-07-30 (Campaign P final physics slice) — byte-proven.** Raw bytes of `CPhysicsObj::calc_friction @ 0x0050ee70`'s Sledding fast-sled branch (`0x0050ef52-0x0050ef6a`) show a genuine `fcos` opcode over the real 10°-in-radians double literal `0.17453292519943295` at `0x007c6b28` — not a BN misdecompile of a raw float load. Retail truly computes `cos(10°) ≈ 0.9848078` at runtime; ACE's `0.99999536f` is `cos(0.1745 DEGREES)`, the same literal evaluated in degree mode — a proven ACE porting error. `calc_friction` now compares `GroundNormal.Z > 0.98480775f`. | `src/AcDream.Core/Physics/PhysicsBody.cs` (`calc_friction`, the Sledding near-flat branch); `tests/AcDream.Core.Tests/Physics/PhysicsBodyTests.cs` (`calc_friction_sledding_fast_override_engages_at_5_degrees_from_flat`, `..._does_not_engage_at_15_degrees_from_flat`) | — | — | `CPhysicsObj::calc_friction` pc:276694-276822 (0050ee70); raw byte decode `docs/research/2026-07-30-ts4-116-oracle-plan.md` Addendum | -| AD-56 | A body falling PERFECTLY PLUMB (zero horizontal velocity) onto a steep-but-below-FloorZ polygon (LandingZ-permissive, e.g. a steep roof) freezes at its landing position forever once Path 6's steep-poly shortcut is removed (TS-4). `AdjustOffset`'s crease projection (`Cross(ContactPlane.Normal, SlidingNormal)`) against a purely-Z gravity offset is mathematically annihilated (`Dot(slideOffset, offset) = 0` exactly, since `slideOffset.Z = 0` and the offset is purely Z), tripping the abort-small-offset guard before `TransitionalInsert` can run again | `src/AcDream.Core/Physics/TransitionTypes.cs` (`AdjustOffset`'s crease-projection math, shared by every mover); pinned by `tests/AcDream.Core.Tests/Physics/Ts4SteepRoofWedgeCaptureTests.cs` (`FallOntoSteepSlope_PureVertical_FreezesAtDegenerateFixedPoint_RetailParity`) | Filed 2026-07-30 at the Campaign P final physics slice, split out of the retired TS-4 row. This is not a code bug: the mechanism is present identically in the raw retail decomp, ACE's port, and this port (`docs/research/2026-07-30-ts4-116-oracle-plan.md` §1.2 Step E, §1.3) — every one of the three references crushes a purely-vertical offset to zero the same way. A live player almost never produces this exact input: WASD, camera-relative movement, and even small numerical noise inject some horizontal component, which the SAME cross product does NOT annihilate (only a component exactly along the downhill/gravity line is removed) — confirmed by the decisive companion fixture `FallOntoSteepSlope_WithHorizontalVelocity_...`, which converges cleanly with a mere ±0.3 m/s residual horizontal component | A hypothetical mover that manages a truly zero-horizontal-velocity approach to a steep-but-LandingZ-permissive surface (a vertical-drop elevator platform, a scripted teleport landing) would freeze identically to retail; not reachable by ordinary player/NPC movement | `CTransition::adjust_offset` pc:272271-272393 (0x0050a370); `docs/research/2026-07-30-ts4-116-oracle-plan.md` §1.2 Step E, §1.3, §1.5 | +| AD-55 | `calc_friction`'s Sledding slope-flatness test compares `GroundNormal.Z > 0.99999536f` (≈0.175° from flat); the raw retail decomp literally computes `__fcos(0.17453292519943295)` (= cos(10°) ≈ 0.984808) and compares that against `contact_plane.N.z` — physically very different tests (0.175° accepts only essentially-perfectly-flat ground; 10° accepts any modest slope) | `src/AcDream.Core/Physics/PhysicsBody.cs` (`calc_friction`, the Sledding near-flat branch) | Filed 2026-07-30 splitting AP-7's retirement (Campaign P Slice P2). Two hypotheses, neither confirmed this pass: (a) BN misdecompiled a raw float-constant load as an `__fcos()` call (a known BN artifact class), or (b) ACE's own port made an independent error and cos(10°) is correct. `0.99999536f` is kept provisionally — least churn, since it is what acdream's own prior (structurally unreachable) dead code already had — pending a live Ghidra decompile of `0050ee70` checking whether the FCOS opcode is real or a raw `FLD` of one of these two constants | Currently harmless in production: nothing sets `PhysicsState.Sledding` client-side (see #166 research), so this branch is unreachable either way. The moment a data-authored Sledding toggle exists, the wrong constant changes which slopes get the light 0.2f sled-friction override vs. the heavier default | `CPhysicsObj::calc_friction` pc:276694-276822 (0050ee70), the `__fcos(0.17453292519943295)` slope-flatness comparison; ACE `PhysicsObj.calc_friction` PhysicsObj.cs:2120-2141 (`0.99999536f`); `docs/research/2026-07-30-response-layer-edge-family-pseudocode.md` §1, §7 item 3 | | AD-46 | **LIVE. Reframed at Campaign V slice V11 (2026-07-29), when GL was deleted and the comparison that discovered this row ceased to exist.** Dense alpha-blended distant scenery (the treeline) may read slightly denser than retail's, because the anisotropic TAP PATTERN is implementation-defined and acdream's Vulkan driver does not tap identically to retail's D3D9 one. Both request the same sampler state — trilinear, clamp-and-repeat, the device's maximum anisotropy. **What changed at V11 is only the left-hand side of the comparison**: this was measured GL-vs-Vulkan (~15% of the pixels in the band), and it is now a Vulkan-vs-retail question against the D3D oracle in the last column. The measurement below is retained as the evidence that the residual is a tap pattern and not a bug, even though one of its two arms no longer exists. | `src/AcDream.App/Rendering/Wb/WorldTextureArray.cs` (`RhiWorldTextureArray.WorldArrayAnisotropy`); measured in plan §5.5.19, reframed §5.5.24 | Not assumed — narrowed by measurement while both backends still existed, on an offline capture with no session, no entities and both clocks pinned. Anisotropy 1 → 41,509 differing pixels in the tree band; anisotropy 16 (GL's value, and retail's `m_D3DCaps.MaxAnisotropy`) → 22,266, and the rest of the frame fell to 497 px of 563,200, i.e. 8.8e-04, inside the campaign's 0.001 threshold. The residual was not a sub-pixel shift (an integer shift search found none), not a sharpness change (high-frequency energy matched within 5%), and not depth precision (forcing Vulkan's window-depth range to GL's compressed [0.5, 1] moved it by 3%). Monotone improvement toward GL's own anisotropy with no knob left is what made it a driver property rather than a bug. | Distant foliage shimmers or reads denser than retail's. The class is confined to alpha-blended dense overlap: opaque terrain, roofs, walls, water, statics, the character and the whole retained UI are inside threshold. **Now unfalsifiable by self-differential** — with GL gone, the only way to retire this row is a side-by-side against the retail client, not against another acdream backend. | `RenderDeviceD3D::SetDefaultD3DStates @ 0x005a3800`, whose `SetSamplerState(stage, 0xA /* D3DSAMP_MAXANISOTROPY */, m_D3DCaps.MaxAnisotropy)` at `0x005a4230` is the value acdream requests | | AD-47 | **Filed at Campaign V slice V11 (2026-07-29); the campaign's risk register scheduled this row here.** Multisample resolve sample POSITIONS are unspecified by both the Vulkan and D3D9 specifications, so acdream's MSAA-on silhouette edges do not match retail's pixel-for-pixel even at the same sample count. acdream's strict pixel gates therefore run with MSAA forced OFF on every arm, and MSAA-on gets only a relaxed visual smoke. | `src/AcDream.App/RuntimeOptions.cs` (`ACDREAM_MSAA_SAMPLES`); forced to 0 in `tools/run-offline-pixel-gate.ps1` | Measured, not assumed: plan §5.5.16 compared two backends at 4x and found **8.83% of the frame differing — 81,359 px of 921,600 — essentially all of it hugging foliage and silhouette edges**, which is ninety-fold over the 0.001 gate threshold. That is two implementations' sample patterns, not a renderer divergence, which is why forcing MSAA off is what makes the remaining difference attributable rather than a threshold relaxation. | Edge quality on thin geometry (fence rails, foliage, distant railings) differs from retail at the sub-pixel level whenever MSAA is on, which is the ordinary player configuration. Because the gates run MSAA off, **a real regression confined to the multisample path would not be caught by them** — that is the actual exposure this row records. | D3D9 `D3DRS_MULTISAMPLEANTIALIAS` / `D3DMULTISAMPLE_TYPE` as set by `RenderDeviceD3D::SetDefaultD3DStates @ 0x005a3800`; retail's sample pattern is the driver's, exactly as ours is | | AD-48 | **Filed at Campaign V slice V11 (2026-07-29).** Presentation is paced by the Vulkan swapchain present mode (FIFO, i.e. VSync) or by a refresh-rate software pacer when uncapped, rather than by retail's D3D9 `Present` with its own frame-rate limiter. Frame delivery cadence, and therefore input-to-photon latency, is a property of our present path rather than a port of retail's. | `src/AcDream.App/RuntimeOptions.cs:98-100`; `src/AcDream.App/Rendering/Gpu/Vk/VulkanSwapchain.cs` | Retail's limiter and ours both bound the frame rate to the display; the simulation is fixed-step and clock-driven, so gameplay timing does not ride on presentation cadence. The uncapped path exists for measurement and is not the shipping default. | A pacing mismatch shows up as judder or input latency that differs from retail's feel without any visual difference in a captured frame — invisible to every pixel gate by construction. Issue **#235** (the capped/RDP jump-presentation cadence alias) is the known live instance of this class. | D3D9 `IDirect3DDevice9::Present`; retail's frame limiter in `RenderDeviceD3D` | @@ -242,7 +241,7 @@ AP-94..AP-112 for the confirmed retail-UI completion gaps. | # | Divergence | Where (file:line) | Why it is safe / justified | Risk if assumption breaks | Retail oracle | |---|---|---|---|---|---| | ~~TS-1~~ | **RETIRED 2026-07-30 (Campaign P Slice P2) — the row was stale, not the code.** The cited `:1254` line is unrelated stepping-loop code; the file moved substantially since the row was written. Retail's `EdgeSlide → PrecipiceSlide / CliffSlide` chain is already a real, tested port: `SpherePath.PrecipiceSlide` (`TransitionTypes.cs:943-970`, retail `SPHEREPATH::precipice_slide` pc:274316), `Transition.CliffSlide` (`:2080-2164`, retail `CTransition::cliff_slide` pc:272397, return-value mapping verified against `acclient.h:6100-6108`), and `Transition.EdgeSlideAfterStepDownFailed` (`:1907-2078`, mirrors `CTransition::edge_slide` pc:273001-273090). The one real gap (back-probe fallback skipping retail's `walkable_check_pos`/`localspace_sphere` recache, pc:274318-274326) needed no code change: acdream's `WalkableVertices`/`GlobalSphere` are populated in unified world space at assignment time (`SetWalkable`/`SetWalkableTransformed`, `SetCheckPos`/`RestoreCheckPos`), so both operands `BSPQuery.FindCrossedEdge` compares are already commensurable — retail's per-cell local-frame reprojection is a no-op correction here. Documented in-code at the back-probe site and pinned by `EdgeSlideBackProbePrecipiceSlideTests`. The chain's two acdream-only compensating branches (CliffSlide's three-source reference-normal fallback; the walkable-steepness reroute to CliffSlide before PrecipiceSlide) are real, non-retail additions — filed as AD-53 / AD-54 rather than folded into this row. | `src/AcDream.Core/Physics/TransitionTypes.cs` (`SpherePath.PrecipiceSlide`, `Transition.CliffSlide`, `Transition.EdgeSlideAfterStepDownFailed`); `tests/AcDream.Core.Tests/Physics/EdgeSlideBackProbePrecipiceSlideTests.cs` | — | — | `SPHEREPATH::precipice_slide` pc:274316 (0050cc80); `CTransition::cliff_slide` pc:272397 (0050a6d0); `CTransition::edge_slide` pc:273001-273090 (0050b3d0); `SPHEREPATH::get_walkable_pos`/`cache_localspace_sphere`/`set_walkable_check_pos` pc:274318-274326 (0050a8f0/0050c9d0/00509ce0); `docs/research/2026-07-30-response-layer-edge-family-pseudocode.md` §2, §6 Step 1 | -| ~~TS-4~~ | **RETIRED 2026-07-30 (Campaign P final physics slice) — the Path-6 steep-poly slide-tangent shortcut is deleted from both `BSPQuery.cs` and `FlatBspQuery.cs`.** Every airborne hit (steep or shallow) now falls through to the same unconditional `path.SetCollide(worldNormal); path.WalkableAllowance = LandingZ; return Adjusted;`, matching retail's `BSPTREE::find_collisions` exactly (`acclient_2013_pseudo_c.txt:323783-323821`, `0x0053a793` — no steepness test at the BSP layer at all). The decisive confirming run (`Ts4SteepRoofWedgeCaptureTests`) shows a steep-roof fall carrying a small residual horizontal velocity (the realistic case — WASD input, jump momentum, matching the original 2026-04-30 live repro) converges cleanly to the flat floor with no freeze once the shortcut is removed. Only a PERFECTLY PLUMB drop (zero horizontal velocity, a practically unreachable live-play input) still freezes — see AD-56 for that narrow, retail-matching degenerate case, pinned rather than fixed. | `src/AcDream.Core/Physics/BSPQuery.cs`, `src/AcDream.Core/Physics/FlatBspQuery.cs` (Path 6); `tests/AcDream.Core.Tests/Physics/Ts4SteepRoofWedgeCaptureTests.cs`; `tests/AcDream.Core.Tests/Physics/BSPStepUpTests.cs` (`C3_Path6_AirborneMoverHitsSteepSlope_ReturnsAdjustedAndSetsCollide`, `D4_AirborneMover_TallWall_PersistsSlidingNormalAcrossFrames`) | — | — | `BSPTREE::find_collisions` SetCollide pc:323783-323821 (0x0053a793); `docs/research/2026-07-30-ts4-116-oracle-plan.md` §1, §4 item 2 | +| TS-4 | **RE-OPENED 2026-07-30 after the matrix live gate**: the fixture-gated removal shipped and the user immediately hit the wedge live ("stuck sliding on an edge") plus a non-retail uphill-jump bounce and lost roof slides — the horizontal-velocity convergence claim under-modeled real trajectories. Removal reverted; the oracle plan §7 degenerate analysis needs live-capture-driven rework before any retry. Original row: Path-6 steep-poly slide-tangent shortcut: airborne hits on >FloorZ polys skip retail's SetCollide → Path-4 → ContactPlane landing chain, returning Slid in place. **Includes a `SetSlidingNormal` write at both sites** — retail's BSP layer never writes `collision_info.sliding_normal` (only `validate_transition` 0x0050ac21 does; the #137 mechanism-2 class), so on transition success the steep-face normal persists to the body and seeds the next frame | `src/AcDream.Core/Physics/BSPQuery.cs` (Path-6 steep branches, `worldNormal.Z < FloorZ`) | Deliberate deviation: our faithful port DID wedge (missing step_up_slide / cliff_slide details on grounded-steep); validated against the 2026-04-30 retail cdb trace (retail body didn't wedge). Filed L.5+ for retail-strict | Airborne steep contact never commits Contact / lands as retail — roof-bounce trajectories, landing events, grounded-steep transitions diverge; a persisted steep-face normal can absorb an exactly-anti-parallel next-frame push (#137 wedge class) until an oblique input clears it | `BSPTREE::find_collisions` SetCollide pc:323783-323821 | | TS-6 | Weather particle emission suppressed — all weathery DayGroups map to Overcast (correct fog/cloud tone, no precipitation); retail's camera-attached weather subsystem not yet located in the decomp | `src/AcDream.Core/World/WeatherState.cs:200` | Decomp research verified the sky loop never reads `DefaultPesObjectId`; an earlier name-based rain spawn regressed (rained where retail didn't, 2026-04-23) — inventing a name→rain path is forbidden until the real subsystem is found | Rainy/snowy/stormy days never show retail's precipitation effects (permanent missing visuals until the subsystem is found and ported) | FUN_00508010 / FUN_0051bed0→FUN_0051bfb0 (negative findings) | | TS-7 | SkyObject `weather_enabled` gate not honored — weather-flagged sky objects (bit 0x04) always instantiate | `src/AcDream.Core/World/SkyDescLoader.cs:50` | No weather_enabled toggle exists yet; IsWeather flag parsed + documented as the gate to wire | Weather-only sky meshes (rain cylinders) appear where retail-with-weather-off suppresses them | `GameSky::MakeObject` 0x00506ee0, guard at decomp:268630 | | TS-8 | `MagicUpdateEnchantment` (0x02C2) records carry no StatMod — mid-session buffs don't move vital max until relog (**#7/#12**) | `src/AcDream.Core/Spells/Spellbook.cs:150` | The wire parser hasn't been extended to the full ~60-64 byte Enchantment payload; PlayerDescription's block IS parsed | Vitals HUD percent reads differently from retail for the whole session after any buff cast | `EnchantAttribute` 0x00594570; holtburger magic/types.rs | @@ -307,12 +306,13 @@ phase-gated — they carry their trigger in their row and should land WITH that phase, not before. 1. **TS-27 — INBOUND retransmit handling** — the outbound sent-packet cache + resend landed with Campaign N Slice N1 (2026-07-29, class-doc gap list fixed same commit); the inbound sequence-aligned ISAAC + client NAK emission (N2/N4) remain the hard blocker for non-loopback play — one lost S2C packet still deafens the session permanently. -2. **UN-1 — CheckOtherCells iteration order** — behavior-bearing halt order with a log-cosmetics justification; trivial to fix (iterate CELLARRAY build order, sort only in probe output). -3. **UN-6 — 200 ms ConnectResponse sleep** — unexplained constant on every login with an intermittent-failure shape; either find the ACE race and cite it, or replace with an acknowledged-ready check. -4. **UN-4 — GfxObj sides/negative-surface logic** — diagnose against the retail-cited CellStruct interpretation on a known double-sided GfxObj; promote to AP with a citation or align it. -5. **TS-8 — MagicUpdateEnchantment StatMod parse (#7/#12)** — vitals wrong for the whole session after any buff; parser shape is known from holtburger. -6. **TS-55 — AdminEnvirons fog/radar presentation** — exact retail mechanism is known; port the authored ambient/fog fields, radar blanking, Clear, and `0x270F` together. -7. **TS-19 — Legacy ChaseCamera deletion** — already marked "pending the follow-up deletion commit"; its continued existence can mask or manufacture flap symptoms during debugging. +2. **TS-4 — Path-6 steep slide-tangent shortcut** — landing/contact state diverges on every airborne-steep hit; the L.5+ retail-strict followup is already filed with the missing-ingredient analysis. +3. **UN-1 — CheckOtherCells iteration order** — behavior-bearing halt order with a log-cosmetics justification; trivial to fix (iterate CELLARRAY build order, sort only in probe output). +4. **UN-6 — 200 ms ConnectResponse sleep** — unexplained constant on every login with an intermittent-failure shape; either find the ACE race and cite it, or replace with an acknowledged-ready check. +5. **UN-4 — GfxObj sides/negative-surface logic** — diagnose against the retail-cited CellStruct interpretation on a known double-sided GfxObj; promote to AP with a citation or align it. +6. **TS-8 — MagicUpdateEnchantment StatMod parse (#7/#12)** — vitals wrong for the whole session after any buff; parser shape is known from holtburger. +7. **TS-55 — AdminEnvirons fog/radar presentation** — exact retail mechanism is known; port the authored ambient/fog fields, radar blanking, Clear, and `0x270F` together. +8. **TS-19 — Legacy ChaseCamera deletion** — already marked "pending the follow-up deletion commit"; its continued existence can mask or manufacture flap symptoms during debugging. **Phase-gated (do WITH the phase, flagged here so they aren't forgotten):** M2 combat must land TS-25 diff --git a/src/AcDream.Core/Physics/BSPQuery.cs b/src/AcDream.Core/Physics/BSPQuery.cs index af32bea0..7e314906 100644 --- a/src/AcDream.Core/Physics/BSPQuery.cs +++ b/src/AcDream.Core/Physics/BSPQuery.cs @@ -1979,17 +1979,6 @@ public static class BSPQuery FindWalkableInternal(root, resolved, path, ref validPos, movement, localSpaceZ, ref hitPoly, ref _hitPolyId, ref changed); - // #116 shape-2 instrumentation (Campaign P final physics slice, - // 2026-07-30; docs/research/2026-07-30-ts4-116-oracle-plan.md - // §3.3 step 1): names whether Path 4's find_walkable probe found - // a candidate for this specific poly set, settling the D4 - // first-airborne-frame routing question without a live cdb trace. - if (PhysicsDiagnostics.ProbeIndoorBspEnabled) - { - Console.WriteLine(System.FormattableString.Invariant( - $"[path4-diag] changed={changed} hitPoly={(hitPoly is not null)}")); - } - if (changed && hitPoly is not null) { // ACE: var offset = LocalToGlobalVec(validPos.Center - localSphere.Center) * scale @@ -2207,35 +2196,57 @@ public static class BSPQuery var worldNormal0 = L2W(hitPoly0!.Plane.Normal); - // TS-4 RETIRED (Campaign P final physics slice, 2026-07-30; - // docs/research/2026-07-30-ts4-116-oracle-plan.md §1, §4 item 2). - // The L.4 steep-poly slide-tangent shortcut that used to live - // here (worldNormal0.Z < FloorZ → project-and-Slid, - // SetCollisionNormal + SetSlidingNormal) is deleted. Retail's - // BSP layer never differentiates by slope here — it calls - // SetCollide unconditionally for every hit, steep or shallow - // (acclient_2013_pseudo_c.txt:323783-323821, 0x0053a793; - // no steepness test at this layer at all), and never writes - // collision_info.sliding_normal from the BSP/sphere layer — - // only validate_transition (0x0050ac21/0x0050aa70) does. + // L.4 slide-tangent for steep airborne hits (2026-04-30). // - // The decisive confirming run (Ts4SteepRoofWedgeCaptureTests): - // with the shortcut removed, a steep-roof fall carrying a - // small residual horizontal velocity (the realistic case — - // WASD input, jump momentum) converges cleanly to the flat - // floor with no freeze - // (FallOntoSteepSlope_WithHorizontalVelocity_...). Only the - // DEGENERATE pure-vertical drop (zero horizontal velocity) - // still freezes — and that freeze is retail-faithful too - // (see the pinned FallOntoSteepSlope_NeverFreezesFor... test - // and AD-56 for the mechanism: AdjustOffset's crease - // projection, Cross(ContactPlane.Normal, SlidingNormal), is - // mathematically orthogonal to a purely-Z input offset, - // crushing it to zero every tick and short-circuiting before - // TransitionalInsert runs again — present identically in the - // raw decomp, ACE's port, and this port). + // For polygons too steep to walk on (worldNormal.Z < FloorZ), + // skip the SetCollide → Path-4 → ContactPlane landing chain. + // That chain commits the body to the steep surface, leading + // to the "stuck in falling animation on the roof" bug — once + // grounded with a steep ContactPlane, our step_up_slide / + // cliff_slide / edge_slide chain can't produce smooth + // descent and the body wedges or "falls a bit at a time" + // when bumped. // - // ─── SetCollide response (unconditional, retail-faithful) ── + // Instead: project the move along the steep face (remove + // the into-wall displacement), set CollisionNormal + + // SlidingNormal, return Slid. Same shape as Path 5's + // step-up fallback (line 1545-1547) and CylinderCollision + // (TransitionTypes.cs:1518-1522). Position is updated in- + // place; on the next resolver iteration the sphere is + // outside the poly, FindCollisions returns OK, and + // ValidateTransition commits the new position. Body stays + // airborne, falling animation continues, and gravity's + // tangent component drifts the body downhill until it + // slides off the slope's edge. + // + // This is a deliberate deviation from retail (retail uses + // SetCollide unconditionally and lets find_walkable + + // step_up_slide produce the slide). Validated against + // retail debugger trace 2026-04-30: retail body did not + // wedge; our retail-faithful port DID wedge because we're + // missing implementation details of the step_up_slide / + // cliff_slide chain on grounded-steep movement. The + // slide-tangent here produces user-acceptable behavior + // (slides off naturally) while the deeper chain port is + // researched. Filed as L.5+ followup for retail-strict. + if (worldNormal0.Z < PhysicsGlobals.FloorZ) + { + Vector3 currWorld = path.GlobalCurrCenter[0].Origin; + Vector3 endWorld = path.GlobalSphere[0].Origin; + Vector3 gDelta = endWorld - currWorld; + float diff = Vector3.Dot(worldNormal0, gDelta); + if (diff < 0f) + path.AddOffsetToCheckPos(-worldNormal0 * diff); + + collisions.SetCollisionNormal(worldNormal0); + collisions.SetSlidingNormal(worldNormal0); + // L.2d slice 1 (2026-05-13): diagnostic side-channel. + if (PhysicsDiagnostics.ProbeBuildingEnabled || PhysicsDiagnostics.ProbeIndoorBspEnabled) + PhysicsDiagnostics.LastBspHitPoly = hitPoly0; + return TransitionState.Slid; + } + + // ─── SetCollide response (shallow / walkable) ─────────── // Per retail (acclient_2013_pseudo_c.txt:323783-323821). path.SetCollide(worldNormal0); path.WalkableAllowance = PhysicsGlobals.LandingZ; diff --git a/src/AcDream.Core/Physics/FlatBspQuery.cs b/src/AcDream.Core/Physics/FlatBspQuery.cs index 9f7b800f..dd39e821 100644 --- a/src/AcDream.Core/Physics/FlatBspQuery.cs +++ b/src/AcDream.Core/Physics/FlatBspQuery.cs @@ -2034,18 +2034,24 @@ internal static class FlatBspQuery localToWorld); } - // TS-4 RETIRED (Campaign P final physics slice, 2026-07-30; - // docs/research/2026-07-30-ts4-116-oracle-plan.md §1, §4 item 2). - // Retail's BSP layer has no steepness test at this layer at all - // (acclient_2013_pseudo_c.txt:323783-323821, 0x0053a793) — every - // hit (steep or shallow) falls through to the same unconditional - // SetCollide. The old L.4 slide-tangent shortcut (worldNormal0.Z - // < FloorZ -> project-and-Slid with its own SetSlidingNormal - // write) is deleted; see BSPQuery.cs's Path 6 for the mirrored - // fix and full citation. Kept in parity with BSPQuery.cs per the - // FlatBspQueryDifferentialTests graph-vs-flat comparison. Vector3 worldNormal0 = LocalToWorld( tree.PolygonTable.Polygons[defaultHitPolygonIndex0].Plane.Normal); + if (worldNormal0.Z < PhysicsGlobals.FloorZ) + { + Vector3 currentWorld = + path.GlobalCurrCenter[0].Origin; + Vector3 endWorld = + path.GlobalSphere[0].Origin; + Vector3 globalDelta = endWorld - currentWorld; + float difference = Vector3.Dot(worldNormal0, globalDelta); + if (difference < 0f) + path.AddOffsetToCheckPos(-worldNormal0 * difference); + + collisions.SetCollisionNormal(worldNormal0); + collisions.SetSlidingNormal(worldNormal0); + RecordDiagnosticHit(tree, defaultHitPolygonIndex0); + return TransitionState.Slid; + } path.SetCollide(worldNormal0); path.WalkableAllowance = PhysicsGlobals.LandingZ; @@ -2067,22 +2073,30 @@ internal static class FlatBspQuery if (defaultHit1 || defaultHitPolygonIndex1 >= 0) { - // #116 shape-1 fix (Campaign P final physics slice, - // 2026-07-30; docs/research/2026-07-30-ts4-116-oracle-plan.md - // §2.3-§2.4). Retail's airborne (not-yet-Contact) - // find_collisions dispatch, when the FOOT sphere is - // completely clear but the HEAD sphere hits or near-misses, - // records the head polygon's normal directly and hard-stops - // rather than deferring through SetCollide/Adjusted: - // pc:323824-323834 (0x0053a793/0x0053a7a4), cross-checked - // against ACE BSPTree.cs:221-230. See BSPQuery.cs's Path 6 - // for the mirrored fix and full citation. Vector3 worldNormal1 = LocalToWorld( tree.PolygonTable.Polygons[defaultHitPolygonIndex1].Plane.Normal); + if (worldNormal1.Z < PhysicsGlobals.FloorZ) + { + Vector3 currentWorld = + path.GlobalCurrCenter[0].Origin; + Vector3 endWorld = + path.GlobalSphere[0].Origin; + Vector3 globalDelta = endWorld - currentWorld; + float difference = + Vector3.Dot(worldNormal1, globalDelta); + if (difference < 0f) + path.AddOffsetToCheckPos(-worldNormal1 * difference); - collisions.SetCollisionNormal(worldNormal1); + collisions.SetCollisionNormal(worldNormal1); + collisions.SetSlidingNormal(worldNormal1); + RecordDiagnosticHit(tree, defaultHitPolygonIndex1); + return TransitionState.Slid; + } + + path.SetCollide(worldNormal1); + path.WalkableAllowance = PhysicsGlobals.LandingZ; RecordDiagnosticHit(tree, defaultHitPolygonIndex1); - return TransitionState.Collided; + return TransitionState.Adjusted; } } diff --git a/tests/AcDream.Core.Tests/Physics/BSPStepUpTests.cs b/tests/AcDream.Core.Tests/Physics/BSPStepUpTests.cs index 8ff68869..560db1d6 100644 --- a/tests/AcDream.Core.Tests/Physics/BSPStepUpTests.cs +++ b/tests/AcDream.Core.Tests/Physics/BSPStepUpTests.cs @@ -407,7 +407,7 @@ public class BSPStepUpTests /// the retail step_up_slide / cliff_slide chain port is completed). /// [Fact] - public void C3_Path6_AirborneMoverHitsSteepSlope_ReturnsAdjustedAndSetsCollide() + public void C3_Path6_AirborneMoverHitsSteepSlope_ReturnsSlid() { var (root, resolved) = BSPStepUpFixtures.SlopedUnwalkable(); @@ -427,17 +427,13 @@ public class BSPStepUpTests root, resolved, t, localSphere, null, currPos, Vector3.UnitZ, 1.0f); - // TS-4 RETIRED (Campaign P final physics slice, 2026-07-30; - // docs/research/2026-07-30-ts4-116-oracle-plan.md §1, §4 item 2). - // Retail's BSP layer has NO steepness test at this layer at all - // (acclient_2013_pseudo_c.txt:323783-323821, 0x0053a793) — a steep - // airborne hit now returns Adjusted and sets the Collide flag, - // exactly like a shallow hit. The old L.4 slide-tangent shortcut - // (Slid, no Collide, its own SetSlidingNormal write) is deleted. - Assert.Equal(TransitionState.Adjusted, result); - Assert.True(t.SpherePath.Collide, - "Collide must be set for a steep Path-6 hit, matching retail's " + - "unconditional SetCollide (acclient_2013_pseudo_c.txt:323783-323821)."); + // L.4 slide-tangent (b1af56e, 2026-04-30): steep polygon hit by + // airborne sphere returns Slid (not Adjusted) and does NOT set + // the Collide flag — the into-wall displacement is removed and + // CollisionNormal/SlidingNormal are set instead. + Assert.Equal(TransitionState.Slid, result); + Assert.False(t.SpherePath.Collide, + "Collide must NOT be set when the L.4 steep-slope slide-tangent fires"); } // ========================================================================= diff --git a/tests/AcDream.Core.Tests/Physics/Ts4SteepRoofWedgeCaptureTests.cs b/tests/AcDream.Core.Tests/Physics/Ts4SteepRoofWedgeCaptureTests.cs index 10197e57..29f55a22 100644 --- a/tests/AcDream.Core.Tests/Physics/Ts4SteepRoofWedgeCaptureTests.cs +++ b/tests/AcDream.Core.Tests/Physics/Ts4SteepRoofWedgeCaptureTests.cs @@ -7,58 +7,50 @@ using Xunit.Abstractions; namespace AcDream.Core.Tests.Physics; /// -/// TS-4 RETIRED (Campaign P final physics slice, 2026-07-30; -/// docs/research/2026-07-30-ts4-116-oracle-plan.md §1, §4 item 2). The -/// Path-6 steep-poly slide-tangent shortcut (worldNormal.Z < FloorZ → -/// project-and-Slid, with its own SetSlidingNormal write) is deleted from -/// 's Path 6; both sphere0 and sphere1 steep hits now -/// fall through to the same unconditional SetCollide retail uses for -/// every hit (acclient_2013_pseudo_c.txt:323783-323821, 0x0053a793 — no -/// steepness test at the BSP layer at all). -/// -/// -/// This class builds a dat-free multi-frame replay from the existing -/// geometry (a 63.4° slope, -/// normal.Z ≈ 0.447 — below PhysicsGlobals.FloorZ ≈ 0.6642 but above -/// PhysicsGlobals.LandingZ ≈ 0.0871, exactly the band the retired -/// shortcut used to target) using the same +/// Campaign P Slice P2, TS-4 (Section 6 Step 3): the 2026-04-30 "L.4" fixture +/// capture required before the Path-6 steep-poly slide-tangent shortcut may be +/// removed (docs/research/2026-07-30-response-layer-edge-family-pseudocode.md +/// §4, §6 Step 3). The original repro was a live-client jump onto a steep +/// roof that got the body "stuck in falling animation" for many frames; no +/// captured fixture from that live session survives in the repo (checked +/// docs/research/2026-04-30-* and the L.4 commit `b1af56e`), so this +/// test builds a dat-free multi-frame replay from the existing +/// geometry (a 63.4° +/// slope, normal.Z ≈ 0.447 — below PhysicsGlobals.FloorZ ≈ 0.6642 but +/// above PhysicsGlobals.LandingZ ≈ 0.0871, i.e. exactly the band the +/// L.4 commit's own steep-poly shortcut targets) using the same /// PhysicsEngine.ResolveWithTransition multi-frame replay idiom as -/// Issue185OutdoorStairsSeamReplayTests, gravity integrated between -/// resolves exactly as PhysicsBody.UpdatePhysicsInternal would, for -/// up to 3 simulated seconds (90 ticks at 30 Hz — retail's physics tick -/// rate, #32 L.5). +/// Issue185OutdoorStairsSeamReplayTests. +/// +/// +/// A body falls from directly above the slope's mid-face, integrating +/// gravity between resolves exactly as PhysicsBody.UpdatePhysicsInternal +/// would, for up to 3 simulated seconds (90 ticks at 30 Hz — retail's physics +/// tick rate, #32 L.5). "Wedged" is defined precisely, matching the original +/// bug report ("stuck in falling animation on the roof" for many consecutive +/// frames): the body's position stops changing (within 1 mm) for more than +/// 15 consecutive ticks (0.5 s) while never reaching the flat reference +/// floor at x<0, z=0. A healthy resolution reaches the flat floor (Z ≈ +/// ) well before the 90-tick +/// budget expires, whether it does so by retail's own COLLIDED-then-fall +/// bounce (this file's own git history documents that as retail's actual +/// behavior for a clean Path-6 steep hit with no pre-existing contact plane) +/// or by committing to the steep "walkable" surface via the permissive +/// LandingZ threshold (matching CTransition::check_walkable, +/// pc:273202, 0.0871556997f) and then downhill-drifting off it via +/// the already-ported TS-1 CliffSlide chain. /// /// /// -/// The oracle plan's own root-cause trace (§1.2) found the freeze -/// mechanism one layer downstream of Path 6: Path 6's faithful -/// SetCollide doesn't reposition the sphere; the immediate retry -/// routes to Path 4 (find_walkable), which commits a real steep -/// ContactPlane via the permissive LandingZ gate; the NEXT -/// tick's AdjustOffset then projects the (by-then gravity-only) -/// offset through Cross(ContactPlane.Normal, SlidingNormal) — and -/// for a PURELY VERTICAL offset that cross product annihilates it exactly -/// (§1.2 Step E), tripping the abort-small-offset guard before -/// TransitionalInsert can run again. This is present identically in -/// the raw retail decomp, ACE's port, and this port (§1.2, §1.3) — it is -/// not a bug, it is what a truly zero-horizontal-velocity plumb drop onto a -/// steep surface does in every one of the three references. A live player -/// almost never produces this input (WASD, camera-relative movement, and -/// even float noise inject some horizontal component), which is why the -/// 2026-04-30 live-client debugger trace that originally validated the -/// shortcut never observed the freeze. -/// -/// -/// -/// Two fixtures, two different fates, per the plan's own decisive test -/// (§4 item 2): -/// is the DEGENERATE case (zero horizontal velocity) — PINNED as a known, -/// retail-matching freeze (see register row AD-56). -/// -/// is the REALISTIC case (small residual horizontal velocity, matching the -/// original live repro's actual trajectory shape) — it converges cleanly to -/// the flat floor with no freeze, which is what made TS-4's removal safe to -/// land. +/// Run TWICE across this slice's git history: once with the Path-6 steep +/// shortcut ACTIVE (pins today's baseline — always green, since the +/// shortcut's own in-frame slide-tangent cannot wedge by construction), and +/// once with it REMOVED (the retail-strict candidate). If both pass, TS-4's +/// removal is evidenced safe and lands in the same commit that deletes the +/// shortcut and its SetSlidingNormal writes. If the removed-shortcut +/// run wedges, the shortcut stays and this file's result against ToT is the +/// recorded evidence — see the commit message / research doc open questions +/// for the outcome actually reached. /// /// public class Ts4SteepRoofWedgeCaptureTests @@ -120,26 +112,12 @@ public class Ts4SteepRoofWedgeCaptureTests } /// - /// PINNED known-degenerate case (Campaign P final physics slice, - /// 2026-07-30; docs/research/2026-07-30-ts4-116-oracle-plan.md §1.2-§1.3, - /// §4 item 2; register row AD-56). A body falling PERFECTLY PLUMB (zero - /// horizontal velocity) onto this 63.4° slope's mid-face lands, commits - /// a steep ContactPlane via Path 4's permissive LandingZ - /// gate, and then freezes at that exact position forever: the crease - /// projection inside AdjustOffset - /// (Cross(ContactPlane.Normal, SlidingNormal)) is mathematically - /// orthogonal to a purely-Z offset, crushing it to zero every tick and - /// tripping the abort-small-offset guard before TransitionalInsert - /// runs again. This is retail-faithful — present identically in the raw - /// decomp, ACE's port, and this port (§1.2) — and essentially - /// unreachable in live play, where WASD input, camera-relative movement, - /// and even float noise almost always inject some horizontal component - /// (see - /// for the realistic case, which does NOT freeze). This test PINS the - /// freeze as accepted parity rather than treating it as a bug to fix. + /// Falls a player-flagged mover from directly above the 63.4° slope's + /// mid-face and asserts it reaches the flat floor (or at minimum keeps + /// making downward/downhill progress) without a >0.5s frozen stretch. /// [Fact] - public void FallOntoSteepSlope_PureVertical_FreezesAtDegenerateFixedPoint_RetailParity() + public void FallOntoSteepSlope_NeverFreezesForOverHalfASecond_AndReachesFloor() { var engine = MakeSlopeEngine(); float r = BSPStepUpFixtures.SphereRadius; @@ -152,121 +130,19 @@ public class Ts4SteepRoofWedgeCaptureTests }; // Start well above the slope's mid-face (slope spans x in [0,1], z in - // [0,2] at that x-range), falling straight down with NO horizontal - // component — the degenerate input this pin documents. + // [0,2] at that x-range), falling straight down. Vector3 pos = new(0.5f, 0f, 3.0f); float fallVelocityZ = 0f; uint cell = CellId; - int frozenStreak = 0; - bool frozeAsExpected = false; - Vector3 frozenAtPosition = default; - - for (int tick = 0; tick < MaxTicks; tick++) - { - fallVelocityZ += gravity * dt; - Vector3 target = pos + new Vector3(0f, 0f, fallVelocityZ * dt); - - var result = engine.ResolveWithTransition( - currentPos: pos, - targetPos: target, - cellId: cell, - sphereRadius: r, - sphereHeight: r * 2f, - stepUpHeight: 0.30f, - stepDownHeight: 0.04f, - isOnGround: false, - body: body, - moverFlags: ObjectInfoState.IsPlayer | ObjectInfoState.EdgeSlide, - movingEntityId: 0x01000000u); - - var newPos = result.Position; - float moved = Vector3.Distance(newPos, pos); - - if (moved < WedgeEpsilon) - frozenStreak++; - else - frozenStreak = 0; - - _out.WriteLine( - $"t{tick,3}: pos=({newPos.X:F3},{newPos.Y:F3},{newPos.Z:F3}) " + - $"moved={moved:F4} onGround={result.IsOnGround} onWalkable={result.OnWalkable} " + - $"contact={result.InContact} vz={fallVelocityZ:F2} frozen={frozenStreak}"); - - pos = newPos; - cell = result.CellId; - body.Position = pos; - - if (result.IsOnGround) - fallVelocityZ = 0f; - - if (frozenStreak > WedgeTickThreshold) - { - frozeAsExpected = true; - frozenAtPosition = pos; - break; - } - } - - Assert.True(frozeAsExpected, - $"Expected the degenerate pure-vertical drop to freeze for more than " + - $"{WedgeTickThreshold} consecutive ticks (retail-matching AdjustOffset " + - "crease-projection degeneracy, AD-56) within the {MaxTicks}-tick budget — " + - "it did not. Either the degenerate case no longer reproduces (re-evaluate " + - "this pin against the oracle plan) or an unrelated regression changed the " + - "slope-landing chain."); - Assert.True(frozenAtPosition.X > 0f, - "Expected the freeze to occur ON the steep slope (x>0), not at/after the " + - $"flat reference floor; got x={frozenAtPosition.X:F3}."); - } - - /// - /// Campaign P final physics slice, TS-4 decisive confirming run - /// (docs/research/2026-07-30-ts4-116-oracle-plan.md §1.2 Step E, - /// §1.3, §4 item 2). The pure-vertical fixture above is, per the oracle - /// plan, the DEGENERATE case: AdjustOffset's crease projection - /// (Cross(ContactPlane.Normal, SlidingNormal) against a purely - /// gravity-only offset) is mathematically annihilated by construction - /// when the offset has zero horizontal component — Dot(slideOffset, - /// offset) = 0 exactly, because slideOffset.Z = 0 and the - /// offset is purely Z. Any lateral drift (WASD input, residual jump - /// momentum — present in the original 2026-04-30 live-client repro that - /// validated the shortcut, but NOT in the pure-vertical fixture above) - /// survives that same cross product and should let AdjustOffset - /// produce a small non-zero tangential offset each tick, moving the - /// sphere off the exact collision point, avoiding the abort-small-offset - /// short-circuit, and letting TransitionalInsert run again on - /// subsequent ticks. - /// - [Fact] - public void FallOntoSteepSlope_WithHorizontalVelocity_NeverFreezesForOverHalfASecond_AndReachesFloor() - { - var engine = MakeSlopeEngine(); - float r = BSPStepUpFixtures.SphereRadius; - const float dt = 1f / TicksPerSecond; - const float gravity = -9.8f; - - var body = new PhysicsBody - { - TransientState = TransientStateFlags.Active, - }; - - // Same drop point as the pure-vertical fixture, but with a small - // residual horizontal velocity toward the flat reference floor - // (x<0) — the realistic "jumped/walked onto the roof with some - // drift" case the L.4 shortcut's own validating trace exercised. - Vector3 pos = new(0.5f, 0f, 3.0f); - float fallVelocityZ = 0f; - const float horizontalVelocityX = -0.3f; - uint cell = CellId; - + var positions = new List(MaxTicks) { pos }; int frozenStreak = 0; bool reachedFloor = false; for (int tick = 0; tick < MaxTicks; tick++) { fallVelocityZ += gravity * dt; - Vector3 target = pos + new Vector3(horizontalVelocityX * dt, 0f, fallVelocityZ * dt); + Vector3 target = pos + new Vector3(0f, 0f, fallVelocityZ * dt); var result = engine.ResolveWithTransition( currentPos: pos, @@ -306,6 +182,9 @@ public class Ts4SteepRoofWedgeCaptureTests if (result.IsOnGround) fallVelocityZ = 0f; + positions.Add(pos); + + // Reached the flat reference floor (x<0, z ~ r) — resolved cleanly. if (pos.X < 0f && pos.Z <= r + 0.05f) { reachedFloor = true; @@ -316,6 +195,8 @@ public class Ts4SteepRoofWedgeCaptureTests Assert.True(reachedFloor, $"Body never reached the flat reference floor within {MaxTicks} ticks " + $"({MaxTicks / (float)TicksPerSecond:F1}s); final position " + - $"({pos.X:F3},{pos.Y:F3},{pos.Z:F3})."); + $"({pos.X:F3},{pos.Y:F3},{pos.Z:F3}) — this is the wedge the L.4 shortcut guards " + + "against (never resolving off the steep surface at all), distinct from a bounded " + + "per-tick freeze."); } }