test: remove final campaign labels
This commit is contained in:
Erik
parent
088add2fac
commit
53b6841c5a
8 changed files with 44 additions and 11 deletions
|
|
@ -113,7 +113,7 @@ readiness/requeue adaptation. See
|
|||
" sequences appearing in ACE database strings; server strings carrying REAL line-break characters flow through the same split either way, so the replace only ever fires on content retail would render with a visible backslash-n. | A wire string legitimately containing the two characters backslash+n (a file path, ASCII art in a description) renders with a spurious line break where retail shows it literally. | `ItemExamineUI::AddItemInfo @ 0x004AC050`; `UIElement_Text::AppendTextWithFont` (direct append, no unescape); `StringTableMetaLanguage::UnescapeString @ 0x0067BDC0` (the decode retail applies ONLY at StringInfo resolution) |
|
||||
| AD-108 | **Filed 2026-08-17 at the night-round review fix round (F9); MECHANISM REPLACED the same day at the overnight round's final fix, after live verification found the row's original standalone re-import resolving NOTHING.** Retail authors the Map tab's player-location and house-location icons (`0x100001ED`/`0x100001EE`) as ordinary nested dat children of `m_pMap` (`0x100001EC`) — itself a Type-1 `UIElement_Button`, the GM click-to-teleport feature `gmMapUI::ListenToElementMessage @0x004a2350` idMessage `0x1c` reads — and `gmMapUI::PostInit @0x004a1c70` resolves them as ordinary live child elements. acdream's `UiButton.ConsumesDatChildren` swallows a button's dat children as skin/label parts during the normal import walk, so the two icons never exist in the built tree and `UiElement.FindDescendant` against the page root returns null for them. **The shipped adaptation:** `MapPageController.Bind` finds each icon's `ElementInfo` under `m_pMap`'s own ALREADY-RESOLVED info subtree — `pageInfo`, a subtree of the panel-slot resolve `ImportInfos(dats, 0x2100006E, 0x1000018C)`, the ONLY pathway that materializes these infos at all — and BUILDS it through the new `Bindings.IconBuilder` seam (production: `LayoutImporter.Build(info, ...)` under the DAT lock — the build half of `RowTemplateResolver`'s shape, no import half), attaching the result as a runtime child of the built `m_pMap`. Live-DAT-pinned structural facts (`MapHousePanelLiveDatMountTests`, the pin the original gap proved missing): a cold `ImportInfos(dats, hostLayoutId, iconElementId)` returns null for BOTH icons — its `FindDesc` walks the LayoutDesc's raw top-level `Elements` table (exactly ONE entry for host layout `0x2100006E`) recursing through `ElementDesc.Children`, a purely structural walk with no tab-page/state-descriptor resolution — while the full panel-slot resolve materializes both icons nested under `m_pMap` with real authored extents. (The town-hotspot template `0x100001F0` is different in kind: a genuine standalone catalog entry addressable by `(templateLayoutId, templateElementId)`, whose import-then-build resolution is correct and unchanged.) `ResolveSwallowedIcon` also prefers an icon the normal build walk DID produce (`FindDescendant` under `m_pMap` first), so a future `ConsumesDatChildren` policy change cannot leave a second, permanently-static copy behind the live marker. **Second mechanism half (found by this fix's own F1 live verification):** both icons are detached from the per-frame authored layout pass (`PrepareIcon` sets `Anchors = AnchorEdges.None`, which also clears any imported `LayoutPolicy`) because `PlaceMarker` owns their position outright (retail's `gmMapUI::Update` re-places both markers every tick, and retail's `UpdateForParentSizeChange` runs only on actual parent resize) — acdream re-runs `ApplyAnchor` per frame, and the icon's compatibility anchor had captured the authored `(0,0)` rect while the panel window was still hidden, re-asserting it every frame over PlaceMarker's writes: a live-observed visible green ring pinned to `m_pMap`'s top-left corner regardless of player position, with only the coordinate text correct. | `src/AcDream.App/UI/Layout/MapPageController.cs` (`Bind`'s two `ResolveSwallowedIcon` call sites, `ResolveSwallowedIcon`'s body, `Bindings.IconBuilder`); `src/AcDream.App/UI/RetailUiRuntime.cs` (`MountMapHousePanel`'s `BuildSwallowedIcon`) | The rebuilt icons carry their authored ids and extents — `PlaceMarkerOnMap`'s centering divides the icon's own Width/Height, and the pin test asserts non-degenerate extents on the installed DAT. Their authored local position is irrelevant: `PlaceMarker` overwrites `Left`/`Top` on every 5 s `Refresh`, and each icon starts hidden until the first refresh decides real visibility — same net presentation as retail's find-the-child. | A future DAT regeneration that reauthors the icons OUTSIDE `m_pMap`'s subtree would leave `FindInfo(mapInfo, iconId)` null again — the same silent "[D.2b] … not authored under m_pMap" log-and-hide failure mode this row's original defect had, but now caught by `MapHousePanelLiveDatMountTests` failing on the next suite run instead of only at a connected gate. | `gmMapUI::PostInit @0x004a1c70` (child resolution); `gmMapUI::ListenToElementMessage @0x004a2350` idMessage `0x1c` (confirms `m_pMap` IS a button, not a passive container); `gmMapUI::PlaceMarkerOnMap @0x004a18b0` (the marker math consuming the rebuilt icons) |
|
||||
| AD-106 | **Filed 2026-08-16 at #409 (client-wide retail tooltip system).** Retail's tooltip popup is a separate always-on-top presentation surface — `UIElementManager::StartTooltip @0x00459700` positions and latches it into `m_pTooltipElement`, drawn independently of the ordinary `UIElement` sibling tree (the SAME class of separation the AP-229 register row already establishes for retail's dialogs vs acdream's flat sibling list under one `Host.Root`). `RetailTooltipPresenter` instead mounts the popup as an ordinary `UiRoot` child sibling (`_host.AddChild(root)`) and keeps it topmost by calling `BringToFront` from its OWN `Tick()`, which `RetailUiRuntime.Tick` schedules AFTER both `RetailDialogFactory.Tick()` and `Host.Tick()` in the same frame — guaranteeing the tooltip wins whatever z-order race those two just ran, every frame, regardless of which dialog/screen last called its own `BringToFront`. | `src/AcDream.App/UI/Layout/RetailTooltipPresenter.cs` (`Tick`, `OnTooltipShow`'s `AddChild`/`BringToFront`); `src/AcDream.App/UI/RetailUiRuntime.cs` (`Tick`'s three-call ordering, `MountTooltipPresenter`) | Reproduces the one observable invariant a user can check (tooltips always draw on top of dialogs and screens) without porting retail's literal separate-layer architecture (no second draw pass, no dedicated presentation root) — the SAME tradeoff AP-229 already accepted for dialogs, extended one layer further. The ordering is enforced structurally (three sequential calls in one method), not by convention, so it cannot silently regress from an unrelated edit reordering unrelated `Tick` calls elsewhere. **F10 correction (2026-08-16 review round), two honest additions:** (1) the guarantee is versus dialogs/screens ONLY — `UiRoot.DrawCore`'s own second pass (`ctx.BeginOverlayLayer(); DrawOverlays(ctx); DrawDragGhost(ctx);`) routes open dropdown/menu popups and the drag ghost to a renderer overlay layer that paints over the WHOLE sibling tree unconditionally, so both still paint above a shown tooltip regardless of any `BringToFront` ordering — no z-order fix in the sibling tree can reach that layer. (2) counting the full chain by its own actual participants (not just the three calls local to `RetailUiRuntime.Tick`'s tooltip-adjacent lines), the per-tick `BringToFront` ratchet has FOUR rungs in frame order: `CharacterManagementUiController.Tick`, `CharacterCreationUiController.Tick` (both named in `RetailDialogFactory`'s own GF-15 doc comment as the screens it re-asserts over), `RetailDialogFactory.Tick`, then `RetailTooltipPresenter.Tick`. Four independent per-tick self-reraises stacked by tick ORDER is a design smell — a correct z-order model would need at most one authoritative comparison, not N racing assertions — but is bounded and enumerable in practice (no unbounded surface list, the order is fixed source, not runtime-discovered) so it is left as observed rather than restructured this round. | A FUTURE always-on-top UI surface that calls its own unconditional per-tick `BringToFront` AFTER `TooltipPresenter?.Tick()` in `RetailUiRuntime.Tick`'s ordering could bury a currently-shown tooltip — the exact failure class AP-229 already named for dialogs-vs-screens, now with four layers instead of two. | `UIElementManager::StartTooltip @0x00459700` (`m_pTooltipElement` ownership); AP-229's own dialog/screen precedent |
|
||||
| AD-73 | Filed 2026-08-11 at the Campaign OP OP2 rework (fix round after a double REJECT). `UiTabPanel` (dat Type 8, formerly `UiTabControl`) does NOT perform retail's automatic tab-table wiring / default-page activation at construction. Retail `UIElement_Panel::SetupTabPageHash @0x0046C2E0` + `::Update @0x0046BD00` unconditionally activate the authored default page for ANY instance that carries a tab table. `UiTabPanel` instead stays DORMANT — no click binding, no page-visibility flip, no tab Open/Closed write — until a controller explicitly calls `ActivateTabBehavior()`. | `src/AcDream.App/UI/UiTabPanel.cs` (`ActivateTabBehavior`); factory site `src/AcDream.App/UI/Layout/DatWidgetFactory.cs` (Type-8 arm) | Four already-shipped Type-8 hosts author a tab table today — character sheet root `0x10000227`, spellbook root `0x100002A8`, and vendor `0x100000B8` already implement this exact switching in their own C# controllers (`CharacterStatController`/`SpellbookWindowController`/`VendorUiController`); activating `UiTabPanel`'s own copy unconditionally would double-drive the same page-visibility/tab-state writes those controllers already own. Combat `0x100000A2` has no controller at all and is INTENTIONALLY left inert (its 8 stance pages have no switching UI yet) rather than have `UiTabPanel` silently take ownership. Only newly-authored hosts opt in (Options panel, Campaign OP slice OP3+; Configure Keyboard, OP8). This is what let the unconditional Type-8 factory mapping become safe after the OP2 REJECT (`docs/research/2026-08-11-op2-review-blast.md`, `docs/research/2026-08-11-op2-review-mechanism.md`). | A future panel that authors a Type-8 tab table but never gets a controller call to `ActivateTabBehavior()` renders with every tab button at its authored default (Closed) and every page slot at its default `Visible=true` — i.e. every page overlapping, no single active page — instead of retail's exactly-one-visible-page behavior. This is silent unless the diagnostic `UnresolvedEntries`/`BehaviorActive` surface is checked; a controller author who forgets the activation call will see a visually broken tab host, not a crash. | `UIElement_Panel::SetupTabPageHash @0x0046C2E0`; `UIElement_Panel::Update @0x0046BD00`; `UIElement_Panel::OpenTab @0x0046BE20`. ADDENDUM (2026-08-11, re-review closure): `UiTemplateListBox` additionally reports `ConsumesDatChildren = true` where the pre-rework fallback did not — inert against every shipped layout because no Type-5 element in any of the 32 fixtures authors children (now conformance-PINNED in `OP2ReworkBlastRadiusConformanceTests`, so an authored child appearing in a future DAT regeneration fails the build instead of silently vanishing) |
|
||||
| AD-73 | Filed 2026-08-11 at the Campaign OP OP2 rework (fix round after a double REJECT). `UiTabPanel` (dat Type 8, formerly `UiTabControl`) does NOT perform retail's automatic tab-table wiring / default-page activation at construction. Retail `UIElement_Panel::SetupTabPageHash @0x0046C2E0` + `::Update @0x0046BD00` unconditionally activate the authored default page for ANY instance that carries a tab table. `UiTabPanel` instead stays DORMANT — no click binding, no page-visibility flip, no tab Open/Closed write — until a controller explicitly calls `ActivateTabBehavior()`. | `src/AcDream.App/UI/UiTabPanel.cs` (`ActivateTabBehavior`); factory site `src/AcDream.App/UI/Layout/DatWidgetFactory.cs` (Type-8 arm) | Four already-shipped Type-8 hosts author a tab table today — character sheet root `0x10000227`, spellbook root `0x100002A8`, and vendor `0x100000B8` already implement this exact switching in their own C# controllers (`CharacterStatController`/`SpellbookWindowController`/`VendorUiController`); activating `UiTabPanel`'s own copy unconditionally would double-drive the same page-visibility/tab-state writes those controllers already own. Combat `0x100000A2` has no controller at all and is INTENTIONALLY left inert (its 8 stance pages have no switching UI yet) rather than have `UiTabPanel` silently take ownership. Only newly-authored hosts opt in (Options panel, Campaign OP slice OP3+; Configure Keyboard, OP8). This is what let the unconditional Type-8 factory mapping become safe after the OP2 REJECT (`docs/research/2026-08-11-op2-review-blast.md`, `docs/research/2026-08-11-op2-review-mechanism.md`). | A future panel that authors a Type-8 tab table but never gets a controller call to `ActivateTabBehavior()` renders with every tab button at its authored default (Closed) and every page slot at its default `Visible=true` — i.e. every page overlapping, no single active page — instead of retail's exactly-one-visible-page behavior. This is silent unless the diagnostic `UnresolvedEntries`/`BehaviorActive` surface is checked; a controller author who forgets the activation call will see a visually broken tab host, not a crash. | `UIElement_Panel::SetupTabPageHash @0x0046C2E0`; `UIElement_Panel::Update @0x0046BD00`; `UIElement_Panel::OpenTab @0x0046BE20`. ADDENDUM (2026-08-11, re-review closure): `UiTemplateListBox` additionally reports `ConsumesDatChildren = true` where the pre-rework fallback did not — inert against every shipped layout because no Type-5 element in any of the 32 fixtures authors children (now conformance-PINNED in `DormantDatWidgetConformanceTests`, so an authored child appearing in a future DAT regeneration fails the build instead of silently vanishing) |
|
||||
| ~~AD-53~~ | **RETIRED 2026-07-31 (Campaign P Slice 1B).** `Transition.CliffSlide` now consumes only `collision_info.last_known_contact_plane.N`, exactly as retail does. The invented `LastWalkablePlane -> LastKnownContactPlane -> UnitZ` fallback chain is gone; invalid/default or parallel data takes retail's degenerate `OK_TS` return. | `src/AcDream.Core/Physics/TransitionTypes.cs` (`CliffSlide`); `tests/AcDream.Core.Tests/Physics/RetailEdgeResponseOrderingTests.cs` | — | — | `CTransition::cliff_slide` pc:272397 (0050a6d0); `last_known_contact_plane` maintenance pc:272659-272668 (~0050ad07) |
|
||||
| ~~AD-54~~ | **RETIRED 2026-07-31 (Campaign P Slice 1B).** Every stored walkable polygon now routes unconditionally to `PrecipiceSlide`, including a plane steeper than `FloorZ`; the invented steep-walkable reroute to `CliffSlide` is gone. | `src/AcDream.Core/Physics/TransitionTypes.cs` (`EdgeSlideAfterStepDownFailed`); `tests/AcDream.Core.Tests/Physics/RetailEdgeResponseOrderingTests.cs` | — | — | `CTransition::edge_slide` pc:273001-273090 (0050b3d0) |
|
||||
| ~~AD-55~~ | **RETIRED 2026-07-30 at `252e8068` — and RE-RETIRED 2026-08-07 after a revert resurrected the row text.** The production constant has been the byte-confirmed `0.98480775f` (cos 10°) since `252e8068`, which also struck this row. Five hours later `a8a7d64b` — reverting the UNRELATED TS-4 commit `5e2be19b` — restored this file's older hunk and resurrected the un-struck row while leaving the code fixed. The zombie row then cost a full duplicate byte-derivation on 2026-08-07 (independent confirmation, identical result: qword [0x007c6b28] = π/18 exactly, live FCOS, threshold cos(10°) = 0.984807753; see `docs/research/2026-08-07-ad55-sledding-constant-byte-decode.md`). The old `0.99999536f` was ACE's error — the radian literal evaluated in degree mode — and acdream inherited then corrected it. **Process rule filed to memory: reverting any commit that touched this register must re-verify EVERY row the revert's register hunk touches, because whole-hunk reverts of single-line rows silently undo unrelated row edits.** Original text, retained: `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 |
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ override, no `ClickThrough` write, no `ConsumesDatChildren` override, and its
|
|||
**Do the new pins assert failure modes rather than class names?** Yes, on three
|
||||
of the four axes, with one weaker:
|
||||
|
||||
- **Media drawn** — `OP2ReworkBlastRadiusConformanceTests.cs:48-49`:
|
||||
- **Media drawn** — `DormantDatWidgetConformanceTests.cs:48-49`:
|
||||
`(uint file, int _) = backdrop.ActiveMedia(); Assert.NotEqual(0u, file);`
|
||||
This is the actual draw input, not a class name. ✅
|
||||
- **Click-through** — `:47`, `:67`, `:90`, `:106`, `:155`: `Assert.True(...ClickThrough)`
|
||||
|
|
@ -189,7 +189,7 @@ Three independent checks, all measured:
|
|||
new members are public *fields* (`ElementReader.cs:192`, `:199`, `:207`) and
|
||||
`FixtureLoader` deserializes with `IncludeFields = true`
|
||||
(`FixtureLoader.cs:14-17`), so the fixture path now reads real projected
|
||||
values. Concretely: `OP2ReworkBlastRadiusConformanceTests.cs:64` asserts
|
||||
values. Concretely: `DormantDatWidgetConformanceTests.cs:64` asserts
|
||||
`host.Tabs.Count == 3` and `:127` asserts `== 8` — values that were empty
|
||||
under the stale fixtures. The structural false negative is gone.
|
||||
|
||||
|
|
@ -387,7 +387,7 @@ dat children of their own"), and I verified it — all 16 Type-5 elements, all 3
|
|||
fixtures, zero children.
|
||||
|
||||
**No test pins it.** Worse, the closest pin cannot distinguish the two outcomes:
|
||||
`OP2ReworkBlastRadiusConformanceTests.cs:153` asserts
|
||||
`DormantDatWidgetConformanceTests.cs:153` asserts
|
||||
`Assert.Empty(host.Children)` on effects `0x10000123`, which passes both when no
|
||||
viewport was injected (intended) *and* when authored children were silently
|
||||
consumed (the failure). A future dat/importer change that gives any of the ten a
|
||||
|
|
@ -406,7 +406,7 @@ defensible for the child-count premise, which is per-element.
|
|||
|
||||
### NOTE 1 — the state-propagation pin is a capability assertion
|
||||
|
||||
`OP2ReworkBlastRadiusConformanceTests.cs:91`, `:107` assert
|
||||
`DormantDatWidgetConformanceTests.cs:91`, `:107` assert
|
||||
`IsAssignableFrom<IUiDatStateful>`, not that a `PassToChildren` state actually
|
||||
reached a child. Sound in practice because `TrySetRetailState` is non-virtual
|
||||
(`UiDatElement.cs:86`), so no subclass can diverge — but it is the one MUST-FIX-1
|
||||
|
|
|
|||
|
|
@ -201,7 +201,7 @@ Gap (NOTE, not a miss of the round-1 finding): none of the five exercises
|
|||
`ReadStructMemberId`'s `Enum`/`DataId`/`Integer` kind coercion — every test uses
|
||||
`Enum`. A regression narrowing that coercion would still slip through.
|
||||
|
||||
The blast-radius pins (`OP2ReworkBlastRadiusConformanceTests.cs`) are the other half
|
||||
The blast-radius pins (`DormantDatWidgetConformanceTests.cs`) are the other half
|
||||
of the answer: six built-widget tests across the five pre-existing Type-8 elements and
|
||||
one representative Type-5, asserting `BehaviorActive == false`,
|
||||
`ActivePageElementId == 0`, `ClickThrough == true`, non-zero `ActiveMedia()` on the
|
||||
|
|
|
|||
|
|
@ -334,7 +334,7 @@ makes expression and doc agree by construction.
|
|||
|
||||
### R3 — SHOULD-FIX: the dormant-`ActivePageChanged` pin applies no stimulus
|
||||
|
||||
`tests/AcDream.App.Tests/UI/Layout/OP2ReworkBlastRadiusConformanceTests.cs:83-93`:
|
||||
`tests/AcDream.App.Tests/UI/Layout/DormantDatWidgetConformanceTests.cs:83-93`:
|
||||
|
||||
```csharp
|
||||
var host = Assert.IsType<UiTabPanel>(layout.FindElement(0x100000B8u));
|
||||
|
|
|
|||
|
|
@ -889,3 +889,36 @@ Verification:
|
|||
and
|
||||
- the no-retry complete hermetic Release gate passes 14,379/14,379 with zero
|
||||
skips or failures across all 12 test assemblies.
|
||||
|
||||
## Batch T final campaign-label naming cleanup
|
||||
|
||||
A final class/method-name sweep found one campaign-labelled class and two
|
||||
isolated slice-labelled methods whose names hid otherwise durable behavior.
|
||||
Batch T makes naming-only changes:
|
||||
|
||||
- `OP2ReworkBlastRadiusConformanceTests` becomes
|
||||
`DormantDatWidgetConformanceTests`. Its eight contracts protect dormant
|
||||
Type-5/Type-8 DAT widget behavior, not the OP2 work sequence that discovered
|
||||
the blast radius. Research records retain the OP2 history and now point to
|
||||
the descriptive class name;
|
||||
- `G2_VendorStackSelection_ThroughRealMaterializer_ShowsSplitSlider` becomes
|
||||
`VendorStackSelection_ThroughRealMaterializer_ShowsSplitSlider`; and
|
||||
- `C4_VendorOwnedSplitExemptStackSelection_MatchesRetailsToolbarPresentation`
|
||||
becomes
|
||||
`VendorOwnedSplitExemptStackSelection_MatchesRetailsToolbarPresentation`.
|
||||
|
||||
The detailed G2/C4/AP-169 evidence comments remain beside the two selection
|
||||
tests. No assertion, fixture, product code, or historical research statement
|
||||
was removed. The broader short-label sweep also found complete scenario
|
||||
matrices such as A1-A6/B1-B3/C1-C3/D1-D4; those labels remain because they
|
||||
identify deliberate rows within a documented matrix rather than a stale
|
||||
campaign identity.
|
||||
|
||||
Verification:
|
||||
|
||||
- the focused Batch T filter passes all 10 renamed contracts with zero skips
|
||||
or failures;
|
||||
- the complete 44-project Release build reports zero warnings and zero errors;
|
||||
and
|
||||
- the no-retry complete hermetic Release gate passes 14,379/14,379 with zero
|
||||
skips or failures across all 12 test assemblies.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ namespace AcDream.App.Tests.UI.Layout;
|
|||
/// flip WILL fail here.
|
||||
/// </para>
|
||||
/// </summary>
|
||||
public class OP2ReworkBlastRadiusConformanceTests
|
||||
public class DormantDatWidgetConformanceTests
|
||||
{
|
||||
// ── Type 8 — vendor's media-bearing, tab-table-less backdrop ────────────
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ namespace AcDream.App.Tests.UI.Layout;
|
|||
/// <c>0x64</c>), scrollbar linkage (dat property <c>0x72</c>), the new Type-8/5/
|
||||
/// <c>0x10000036..0x44</c> widget mappings, and <see cref="UiTabPanel"/>'s switch
|
||||
/// behavior. Retail anchors: <c>docs/research/2026-08-10-options-panel-structure.md</c>
|
||||
/// §1.3, §1.5, §10.1. See also <c>OP2ReworkBlastRadiusConformanceTests.cs</c> (built-
|
||||
/// §1.3, §1.5, §10.1. See also <c>DormantDatWidgetConformanceTests.cs</c> (built-
|
||||
/// widget pins for the pre-existing shipped panels the rework's dormancy model
|
||||
/// protects) and the reader-level tests appended to <c>ElementReaderTests.cs</c>.
|
||||
/// </summary>
|
||||
|
|
|
|||
|
|
@ -705,7 +705,7 @@ public class SelectedObjectControllerTests
|
|||
/// </para>
|
||||
/// </summary>
|
||||
[Fact]
|
||||
public void G2_VendorStackSelection_ThroughRealMaterializer_ShowsSplitSlider()
|
||||
public void VendorStackSelection_ThroughRealMaterializer_ShowsSplitSlider()
|
||||
{
|
||||
const uint vendorGuid = 0x70000011u;
|
||||
const uint taperGuid = 0x60009011u;
|
||||
|
|
@ -879,7 +879,7 @@ public class SelectedObjectControllerTests
|
|||
}
|
||||
|
||||
[Fact]
|
||||
public void C4_VendorOwnedSplitExemptStackSelection_MatchesRetailsToolbarPresentation()
|
||||
public void VendorOwnedSplitExemptStackSelection_MatchesRetailsToolbarPresentation()
|
||||
{
|
||||
const uint vendorGuid = 0x70000010u;
|
||||
const uint tradeNotesGuid = 0x60009001u;
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue