From 708e35f610373d45342c2000f9d39f344e783fee Mon Sep 17 00:00:00 2001 From: Erik Date: Sun, 16 Aug 2026 23:02:50 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20hover-feedback=20completion=20round=20?= =?UTF-8?q?=E2=80=94=20#409/#411=20bookkeeping,=20TS-85=20narrowed?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Records the round that shipped item-cell tooltips, the world-object hover tooltip, and the #411 cursor-swap fix: #409's write-up gains a "hover-feedback completion round" section covering all three items with live-verification notes; #411 is closed with the corrected decomp reading; register row TS-85 is narrowed to reflect the two newly-ported SetTooltip call sites (UIElement_UIItem::UpdateTooltip, UIElement_SmartBoxWrapper::RecvNotice_SmartBoxObjectFound) and the still-open ones (spellcasting endowment/cast-button/favorite/submenu, map notes, character-panel attribute/skill info). Co-Authored-By: Claude Fable 5 --- docs/ISSUES.md | 133 ++++++++++++++++-- .../retail-divergence-register.md | 2 +- 2 files changed, 126 insertions(+), 9 deletions(-) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index e636df02..bd214cec 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -26,13 +26,33 @@ What does NOT go here: ## #411 — Hover feedback over interactive UI elements: no cursor swap, and item cells have no rollover state -**Status:** OPEN (filed 2026-08-16 during the #409 live-failure investigation, at the -lead's scope addition; user report: "the cursor should light up when I hover over an -item in inventory. it does not") +**Status:** CLOSED 2026-08-16 at the #409 hover-feedback completion round — the +user's answer to the open question below ("the POINTER changes, like it already +does over world NPCs") is CONFIRMED by decomp, not merely a memory to trust: +`UIElement_SmartBoxWrapper::FindObject @0x004E5430` calls +`SmartBox::set_found_object(itemID)` UNCONDITIONALLY whenever the hovered UI +element casts to `UIElement_UIItem` — not gated on target mode, as the port plan +below (written before this finding) assumed it would need to be. Fixed with a +ONE-LINE widening of `CursorFeedbackController.Update(UiRoot)`'s existing +(too-narrow) item-hover special case; `ResolveGlobalKind` needed no changes, +since it already read the "found" flag unconditionally across every mode. See +docs/ISSUES.md #409's own "hover-feedback completion round" write-up (item 3) +for the full derivation and `CursorFeedbackControllerTests. +UpdateFromRoot_HoveringAnItemSlot_ShowsFoundCursor_In{OrdinaryPeaceMode,CombatMode}` +for the pin. The rollover-STATE half of this investigation (item 3 below, +`UiItemSlot` has no `HoverEnter`/`HoverLeave`) was NOT in scope for the pointer +question and remains unaddressed if the user separately wants the highlight — +file a fresh issue if so; this closure covers only the pointer-swap question the +lead's scope addition asked about. + **Severity:** LOW (cosmetic/affordance; no gameplay impact) **Depends on:** nothing — the hover dispatch it needs is already correct (see #409's live-failure round, which proved `UiRoot.UpdateHover` selects the right widget). +**Original investigation (below), kept for its still-valid layer 1/2/3 breakdown — +only the "never fires over an inventory item" conclusion for layer 2 was +incomplete; see the closure note above for the corrected reading.** + **Retail mechanism, derived from `docs/research/named-retail/acclient_2013_pseudo_c.txt`.** There are THREE separate hover-feedback layers, and the DAT decides which one applies: @@ -188,7 +208,7 @@ horizontal `HJustify` mapping while in this code, since it shares the ## #409 — Client-wide UI tooltip system is unshipped (GF-16, deferred out of Campaign CC gate round 1) -**Status:** CODE-COMPLETE 2026-08-16; review-fix round F1-F11 and the LIVE-FAILURE round both landed same day. The live-failure round's own fix is LIVE-VERIFIED (Options -> Character tab tooltip observed on a real connected client, screenshot evidence); the user's full connected gate is still owed. +**Status:** CODE-COMPLETE 2026-08-16; review-fix round F1-F11, the LIVE-FAILURE round, and the hover-feedback completion round (item-cell tooltips + world-object hover tooltip) all landed same day. The live-failure round's own fix is LIVE-VERIFIED (Options -> Character tab tooltip observed on a real connected client, screenshot evidence); the hover-feedback completion round's three items are automated-gate-verified (unit + live-DAT) but the user's connected gate for THOSE items specifically is still owed — see that round's own "Live-verify all three" note. **Severity:** LOW-MEDIUM (cosmetic/discoverability — no gameplay impact, but retail shows a tooltip on hover for authored elements client-wide and acdream showed none before this fix) **2026-08-16 re-derivation + port.** Full re-derivation from @@ -353,16 +373,113 @@ the "Slots" button. spin arrows — longer text, should WRAP rather than run off-screen; (7) the Heritage/Profession/Skills/Town/Summary tab buttons. -*Expected NOT to show anything yet (deferred, register TS-85):* hovering an -inventory ITEM icon. Retail shows the item name there -(`UIElement_UIItem::UpdateTooltip @0x004E1CB0`); acdream shows nothing. - Confirm also: the box sits offset down-right of the cursor (retail's +32px on both axes), never runs off the edge of the window even near a corner, and disappears on its own after ~10 s if you hold still without moving away. No click-to-dismiss is expected — only moving off the control, or a very long hold, closes it. +**2026-08-16 hover-feedback completion round.** Closes the two items the +live-failure round explicitly deferred (item-cell tooltips, and the #411 +pointer question), plus the world-object hover tooltip the user's gate notes +called out separately. + +1. **Inventory/shortcut/paperdoll item-name tooltips — SHIPPED.** + `UIElement_UIItem::UpdateTooltip @0x004E1CB0` is called from + `UIItem_Update` (an item-DATA-CHANGE refresh, not a hover handler — the + trigger that actually SHOWS it is the generic `CheckTooltip` dwell timer, + same as any other tooltip-bearing element). Re-derived and closed the gap + the live-failure round left open ("acdream's `UiItemSlot` carries neither + the `P0x47` popup locator nor a name source"): live-DAT sweep of the + shared UIItem cell-template catalog (`ItemListCellTemplate.CatalogLayoutId`, + `0x21000037`) found ALL 47 UIItem-type (class `0x10000032`) prototypes — + inventory's cell, every toolbar slot, every paperdoll/armor slot skin — + resolve the IDENTICAL popup locator (`P0x47=0x10000395`/`P0x48=0x21000041`) + through catalog inheritance, with no literal text authored on any of them + (`TooltipLiveDatTests.UiItemCatalog_EveryPrototype_SharesTheSamePopupLocator`). + `UiItemSlot` now hardcodes that pair and exposes `GetTooltipText()` via a + new per-instance `TooltipTextResolve` delegate, wired at every physical- + item construction site — `InventoryController` (main-pack cell + grid + cells), `ExternalContainerController`, `PaperdollController` (closes the + `gmPaperDollUI::UpdateItemSlotTooltip @0x004A52EF` row too — same cell + class, same fix), `VendorUiController` (shop/buying/selling lists), + `SecureTradeUiController`, `ToolbarController`. Text is + `ClientObject.GetTooltipDisplayName()` (new Core method): `GetAppropriateName()` + prefixed with the stack count via `"{count} {name}"` when `StackSize > 1`, + matching `UpdateTooltip`'s exact `NAME_APPROPRIATE` + `"%d %s"` sprintf. + `UiCatalogSlot` (spell/component catalog cells — a DIFFERENT `UiItemSlot` + subclass) is unaffected; it already overrides `GetTooltipText()` with its + own `Label`. + +2. **World-object hover tooltip (NPCs, players, signs, chests, portals) — + SHIPPED.** NOT the UI-element dwell-timer path — retail's mechanism is + `UIElement_SmartBoxWrapper::RecvNotice_SmartBoxObjectFound @0x004E5AD0`, + fed every frame by `FindObject @0x004E5430`/`Global_Loop @0x004E5620` + using the current mouse position regardless of input focus. It fires + IMMEDIATELY (no dwell wait) on the found-object id CHANGING, gated by the + `PlayerModule::ShowTooltips` character option (`CharacterOptionId.ShowTooltips` + — already modeled in `CharacterOptionTable`, default true), with text + `ACCWeenieObject::GetObjectName(id, NAME_APPROPRIATE, 0)` — the SAME name + call as item tooltips, but WITHOUT the item-cell's separate stack-count + prefix (a real, decomp-confirmed asymmetry: a ground pile of arrows shows + "Arrows", not "20 Arrows"). Ported as `RetailTooltipPresenter. + UpdateWorldHoverTooltip`, driven by the SAME world-hover pick + `CursorFeedbackController`'s own found-cursor already uses + (`WorldSelectionQuery.PickAtCursor`, `includeSelf: true`) and the SAME + `ClientObjectTable`-backed name resolver `SocialAllegiancePageController`'s + `ResolveWorldObjectName` already established as this codebase's pattern. + Queried only when no UI element is hovered (this port's reading of + `FindObject`'s `m_pElementLastOver` check, narrowed from retail's literal + "raycast even under non-item UI chrome" — see the class's own doc note). + **Own player is included** (`includeSelf: true`, the same precedent the + cursor feedback wiring already set) — no decomp evidence was found either + confirming or excluding self from the found-object pipeline, so this + follows the established local precedent rather than guessing fresh; flag + if that reads wrong in the live gate. **The exact popup skin is an + inference, not a measured value** — an exhaustive live-DAT sweep found + `UIElement_SmartBoxWrapper` (class `0x10000030`) has NO authored + `ElementDesc` anywhere installed (unlike every other tooltip trigger, it + is evidently constructed directly by `gmGamePlayUI`'s own mode setup, not + from a walkable LayoutDesc — `TooltipLiveDatTests. + SmartBoxWrapper_HasNoAuthoredElementDesc_AnywhereInstalled`), so its real + `P0x47`/`P0x48` cannot be read off the DAT the way the item catalog's can. + This port reuses the SAME pair every other game-code `SetTooltip` caller + in this family resolves to — the best-evidenced choice, called out in + register row TS-85 rather than silently assumed exact. + +3. **#411 resolved: retail DOES swap the pointer over inventory items, + unconditionally — the earlier investigation's "never fires over an + inventory item" finding was INCOMPLETE, not wrong about what it checked.** + The original #411 scan (below) correctly found no PER-ELEMENT authored + cursor on item cells and correctly found `SmartBox::get_found_object_id()` + is written only by `UIElement_SmartBoxWrapper` — but it had not yet traced + `FindObject @0x004E5430` far enough: when the currently-hovered UI element + (`m_pElementLastOver`) casts to `UIElement_UIItem` (class `0x10000032`), + `FindObject` calls `SmartBox::set_found_object(itemID, 0xFFFFFFFF)` + directly and returns WITHOUT running the 3D raycast — UNCONDITIONALLY, not + gated on target mode. `ClientUISystem::UpdateCursorState @0x00564630` + computes its "found" flag ONCE at the top of the function + (`ebx = SmartBox::get_found_object_id() != 0`, `@0x00564642`) and every + later branch (default/melee-missile/magic/use/examine/use-target/busy) + reads that SAME flag — so hovering an occupied item cell shows the + cursor's "...Found" variant in EVERY mode, not only during an active + `UseTarget` selection. `CursorFeedbackController.Update(UiRoot)` already + had the item-hover special case wired (from an earlier round) but + incorrectly gated it to `TargetMode.UseTarget` only; that one-line gate is + now removed — `ResolveGlobalKind`'s existing found/not-found branching + needed no changes at all, since it already read the snapshot's + `HoverTargetGuid` unconditionally across every mode. Live-DAT-independent + (pure decomp + unit fixture), so no DAT sweep was needed for this part; + two new `CursorFeedbackControllerTests` pin the widened behavior in + ordinary peace mode and in combat mode. + +**Live-verify all three on the connected client** (session-config launch, +graceful close per the usual rules): hover an inventory item — a name +tooltip should appear (with a count prefix for a stack) AND the mouse +pointer should swap to its "found" variant; hover an NPC/creature — a name +tooltip should appear immediately (no perceptible delay) if "Show Tooltips" +is on; hover a sign/chest/portal similarly. + --- **Original GF-16 filing (superseded by the re-derivation above; kept for diff --git a/docs/architecture/retail-divergence-register.md b/docs/architecture/retail-divergence-register.md index aacf570c..13e9c959 100644 --- a/docs/architecture/retail-divergence-register.md +++ b/docs/architecture/retail-divergence-register.md @@ -410,7 +410,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-85 | **Filed 2026-08-16 at #409 (client-wide retail tooltip system); REWRITTEN at the same-day F3 review round; NARROWED again at the same-day live-failure round.** LIVE-FAILURE-ROUND NARROWING: the `m_TTText` READ side is now ported — `RetailTooltipPresenter.ResolveTooltipText` consults `UiElement.GetTooltipText()` (this port's `m_TTText`) BEFORE the authored `P0x49`, exactly as `StartTooltipAtMouse @0x00460DA3`/`@0x00460DDF` orders them, and the `P0x48`-absent fallback to the element's own layout (`@0x00460E7E`) is ported through `UiElement.SourceLayoutDid`. That lit up every acdream surface whose controller ALREADY writes runtime tooltip text (the four Options tabs, Configure Keyboard, the social pages) — live-verified 2026-08-16 on the Character tab. What remains deferred is the WRITE side at the retail `SetTooltip` call sites acdream has no analog for yet, enumerated below. Two sub-mechanisms of retail's tooltip system are unported. **(1) The `m_TTText`/`SetTooltip` runtime-text family (headed by the `P0xD0` truncated-text auto-tooltip):** the ORIGINAL filing argued this port's gap was "retail's dynamic `InqProperty(0x49)` override" — that framing is false. `UIElement::InqProperty @0x004638D0`, the BASE implementation every element uses unless its own class overrides the virtual, reads exactly the same authored property bags (`m_instanceProperties`, `m_curStateDesc`, `m_desc`) this port's `ElementReader` already walks generically — so an element with no literal `P0x49` gets NOTHING from retail's own default `InqProperty` either. The REAL second text source is the element's cached `m_TTText` field, set ONLY by the explicit, non-dat `UIElement::SetTooltip` call (`UIElement::StartTooltipAtMouse @0x00460D70` prefers `m_TTText` over the `InqProperty` fallback whenever it is non-empty). `SetTooltip` has 15+ known game-code call sites (Options rows `@0x00485E65`, chargen `@0x00481981`, the paperdoll endowment icon `@0x004C63A1`, the spellcast button `@0x004C6FE8`/`@0x004C6AAE`, and more), headed by the highest-volume one: `UIElement_Text::RecalculateTruncation @0x00466F80`, gated on authored `P0xD0` — an overflowing single/wrapped line calls `SetTooltip(this, ownText) @0x00467064` + sets enable bit 5 `@0x00467076`; a line that now fits calls `ClearTooltip @0x00467064`/clears the bit `@0x00466ff9`. `RecalculateTruncation`'s own truncation-POSITION computation (the rest of the function, `@0x004670a1` onward) walks a `GlyphList` per-line-position model (`FindCompleteLineFromY`/`FindPosFromLineAndPixels`/`FindPixelsFromPos`) this port's `UiText` has no equivalent of — `UiText` clips visually via a scissor rect (`DrawClippedText`'s `PushClip`) with no tracked "does this line overflow" state at all, so porting the auto-tooltip trigger requires building that state first. Sized as genuinely disproportionate for a single fix-round commit alongside F1-F2/F4-F11 and deferred here rather than shipped as a partial/unverified stub. A live-DAT sweep found 187 of the 430 elements authoring at least one tooltip-trigger property have NO literal `P0x49` `StringInfo` text; the live-failure round re-measured that set and found every one of the 187 authors BOTH popup-locator ids (`P0x47`+`P0x48`) — i.e. they are runtime-`SetTooltip` targets by construction, waiting only for text. The 15 `SetTooltip` call sites, enumerated from the decomp at the live-failure round, split into: PORTED (an acdream controller already writes the text, and the presenter now reads it) — the Options rows `@0x00485E65`/`@0x00484803`/`@0x00487053`, chargen skills `@0x00481981`, the radar `@0x004D9605`; NO ACDREAM ANALOG YET — inventory/shortcut item hover `UIElement_UIItem::UpdateTooltip @0x004E1CB0` (retail shows the item NAME, quantity-prefixed `"%d %s"` when stack > 1; measured live 2026-08-16 to show nothing in acdream, and the highest-value remaining gap since acdream's `UiItemSlot` is constructed programmatically and so carries neither `P0x47` nor a name source), the paperdoll equip slots `gmPaperDollUI::UpdateItemSlotTooltip @0x004A52EF`, the spellcasting endowment icon `@0x004C63A1` / cast button `@0x004C6FE8` / favorite `@0x004C7206` / submenu `@0x004C67D8`, the map notes `gmMapUI::AddMapNote @0x004A1C51` (no acdream map UI), the SmartBox found-object `@0x004E5D74`, and the character-panel `AttributeInfoRegion @0x004F1617` / `Attribute2ndInfoRegion @0x004F1777` / `SkillInfoRegion @0x004F222F` constructors. Retail's runtime sites also SET the `P0x4B` on-bit themselves (`__bitfield164 |= 0x20`, eight sites) — the port models that as "runtime text present implies tooltip-on", so only the authored-text path consults the authored bit. **(2) The per-element wrap-width override:** `UIElement_Text::InqSizewMargins @0x00469660`'s `UITS_MAX_WIDTH` branch checks `GetAttribute_Int(this, 0x3D, ...)` before falling back to `RenderDevice::GetDisplayWidth()`; `RetailTooltipPresenter.ApplyTooltipText` always wraps at `UiRoot.EffectiveCanvasSize.X` (the confirmed fallback) and never checks for a `P0x3D` override — the live-DAT sweep found zero tooltip-bearing elements author one. | `src/AcDream.App/UI/Layout/RetailTooltipPresenter.cs` (`ResolveTooltipText`'s runtime-then-authored order; `ApplyTooltipText`'s wrap-width literal); `src/AcDream.App/UI/Layout/ElementReader.cs` (`ElementInfo.TooltipText`'s own doc comment carries the same F3 correction) | The 243 elements WITH literal text — the "core" case #409 ships — cover every hover-text scenario the investigation's own landmark checks exercised (main-game-UI Appearance-page rotate/color/spin hints, etc.). F9 correction: "243 with literal text" is not automatically "243 showable" — `RetailTooltipPresenter.OnTooltipShow`'s real gate is the FULL conjunction of `TooltipEnabled` (P0x4B) AND non-null text (P0x49) AND both popup-locator ids (P0x47/P0x48) — so this was measured, not assumed: `TooltipLiveDatTests.ClientWideSweep_FindsKnownLandmarksAndAFloorCount`'s `Showable` column finds the intersection is exactly 243, i.e. every element authoring literal text also authors the other three properties together (they are evidently authored as one group in practice). The P0x3D sweep found zero authoring elements, so the unconditional display-width fallback is not an approximation for any element that exists today. | If a future DAT revision adds a `P0xD0`-truncated text element, a game-code `SetTooltip` caller, or authors a `P0x3D` override, it silently shows no tooltip / wraps at the wrong width instead of erroring — indistinguishable from "the element authors no tooltip at all" without re-running the sweep AND separately auditing which of the 187 no-literal-text elements would actually truncate at their authored width. | `UIElement::InqProperty @0x004638D0` (base authored-bag read, NOT a dynamic override); `UIElement::StartTooltipAtMouse @0x00460D70` (`m_TTText`-vs-`InqProperty` preference order); `UIElement_Text::RecalculateTruncation @0x00466F80` (`P0xD0` gate, `SetTooltip`/`ClearTooltip` sites); `UIElement_Text::InqSizewMargins @0x00469660` (`UITS_MAX_WIDTH` branch, `GetAttribute_Int(this, 0x3D, ...)`) | +| TS-85 | **Filed 2026-08-16 at #409 (client-wide retail tooltip system); REWRITTEN at the same-day F3 review round; NARROWED again at the same-day live-failure round.** LIVE-FAILURE-ROUND NARROWING: the `m_TTText` READ side is now ported — `RetailTooltipPresenter.ResolveTooltipText` consults `UiElement.GetTooltipText()` (this port's `m_TTText`) BEFORE the authored `P0x49`, exactly as `StartTooltipAtMouse @0x00460DA3`/`@0x00460DDF` orders them, and the `P0x48`-absent fallback to the element's own layout (`@0x00460E7E`) is ported through `UiElement.SourceLayoutDid`. That lit up every acdream surface whose controller ALREADY writes runtime tooltip text (the four Options tabs, Configure Keyboard, the social pages) — live-verified 2026-08-16 on the Character tab. What remains deferred is the WRITE side at the retail `SetTooltip` call sites acdream has no analog for yet, enumerated below. Two sub-mechanisms of retail's tooltip system are unported. **(1) The `m_TTText`/`SetTooltip` runtime-text family (headed by the `P0xD0` truncated-text auto-tooltip):** the ORIGINAL filing argued this port's gap was "retail's dynamic `InqProperty(0x49)` override" — that framing is false. `UIElement::InqProperty @0x004638D0`, the BASE implementation every element uses unless its own class overrides the virtual, reads exactly the same authored property bags (`m_instanceProperties`, `m_curStateDesc`, `m_desc`) this port's `ElementReader` already walks generically — so an element with no literal `P0x49` gets NOTHING from retail's own default `InqProperty` either. The REAL second text source is the element's cached `m_TTText` field, set ONLY by the explicit, non-dat `UIElement::SetTooltip` call (`UIElement::StartTooltipAtMouse @0x00460D70` prefers `m_TTText` over the `InqProperty` fallback whenever it is non-empty). `SetTooltip` has 15+ known game-code call sites (Options rows `@0x00485E65`, chargen `@0x00481981`, the paperdoll endowment icon `@0x004C63A1`, the spellcast button `@0x004C6FE8`/`@0x004C6AAE`, and more), headed by the highest-volume one: `UIElement_Text::RecalculateTruncation @0x00466F80`, gated on authored `P0xD0` — an overflowing single/wrapped line calls `SetTooltip(this, ownText) @0x00467064` + sets enable bit 5 `@0x00467076`; a line that now fits calls `ClearTooltip @0x00467064`/clears the bit `@0x00466ff9`. `RecalculateTruncation`'s own truncation-POSITION computation (the rest of the function, `@0x004670a1` onward) walks a `GlyphList` per-line-position model (`FindCompleteLineFromY`/`FindPosFromLineAndPixels`/`FindPixelsFromPos`) this port's `UiText` has no equivalent of — `UiText` clips visually via a scissor rect (`DrawClippedText`'s `PushClip`) with no tracked "does this line overflow" state at all, so porting the auto-tooltip trigger requires building that state first. Sized as genuinely disproportionate for a single fix-round commit alongside F1-F2/F4-F11 and deferred here rather than shipped as a partial/unverified stub. A live-DAT sweep found 187 of the 430 elements authoring at least one tooltip-trigger property have NO literal `P0x49` `StringInfo` text; the live-failure round re-measured that set and found every one of the 187 authors BOTH popup-locator ids (`P0x47`+`P0x48`) — i.e. they are runtime-`SetTooltip` targets by construction, waiting only for text. The 15 `SetTooltip` call sites, enumerated from the decomp at the live-failure round, split into: PORTED (an acdream controller already writes the text, and the presenter now reads it) — the Options rows `@0x00485E65`/`@0x00484803`/`@0x00487053`, chargen skills `@0x00481981`, the radar `@0x004D9605`; PORTED 2026-08-16 (hover-feedback completion round, docs/ISSUES.md #409/#411): inventory/shortcut item hover `UIElement_UIItem::UpdateTooltip @0x004E1CB0` — `UiItemSlot` now hardcodes the catalog's uniform popup locator (`P0x47=0x10000395`/`P0x48=0x21000041`, live-DAT-confirmed uniform across all 47 UIItem-type catalog prototypes, `TooltipLiveDatTests.UiItemCatalog_EveryPrototype_SharesTheSamePopupLocator`) and a `TooltipTextResolve` delegate wired at every physical-item construction site (inventory, external container, paperdoll — closing the separate `gmPaperDollUI::UpdateItemSlotTooltip @0x004A52EF` row below too, vendor, secure trade, toolbar), backed by the new `ClientObject.GetTooltipDisplayName()` (NAME_APPROPRIATE + the `"%d %s"` stack-count prefix, matching the decomp exactly); and the SmartBox found-object world-hover tooltip `UIElement_SmartBoxWrapper::RecvNotice_SmartBoxObjectFound @0x004E5AD0` (`@0x004E5D74`/`@0x004E5DFB`) — `RetailTooltipPresenter.UpdateWorldHoverTooltip` ports its edge-fired (no dwell), `PlayerModule::ShowTooltips`-gated, `GetAppropriateName`-only (no stack prefix — a real, decomp-confirmed asymmetry vs. the item-cell case) trigger, reusing the SAME popup locator since an exhaustive DAT sweep found `UIElement_SmartBoxWrapper` (class `0x10000030`) has no authored `ElementDesc` anywhere installed (`TooltipLiveDatTests.SmartBoxWrapper_HasNoAuthoredElementDesc_AnywhereInstalled`) — the popup-skin choice is therefore the best-evidenced inference, not a measured value, and is called out here as such. STILL NO ACDREAM ANALOG — the spellcasting endowment icon `@0x004C63A1` / cast button `@0x004C6FE8` / favorite `@0x004C7206` / submenu `@0x004C67D8` (all `UiCatalogSlot`-based, which already has its own independent `Label`-driven `GetTooltipText` — a real gap only if that Label wiring turns out incomplete, unaudited this round), the map notes `gmMapUI::AddMapNote @0x004A1C51` (no acdream map UI), and the character-panel `AttributeInfoRegion @0x004F1617` / `Attribute2ndInfoRegion @0x004F1777` / `SkillInfoRegion @0x004F222F` constructors. Retail's runtime sites also SET the `P0x4B` on-bit themselves (`__bitfield164 |= 0x20`, eight sites) — the port models that as "runtime text present implies tooltip-on", so only the authored-text path consults the authored bit. **(2) The per-element wrap-width override:** `UIElement_Text::InqSizewMargins @0x00469660`'s `UITS_MAX_WIDTH` branch checks `GetAttribute_Int(this, 0x3D, ...)` before falling back to `RenderDevice::GetDisplayWidth()`; `RetailTooltipPresenter.ApplyTooltipText` always wraps at `UiRoot.EffectiveCanvasSize.X` (the confirmed fallback) and never checks for a `P0x3D` override — the live-DAT sweep found zero tooltip-bearing elements author one. | `src/AcDream.App/UI/Layout/RetailTooltipPresenter.cs` (`ResolveTooltipText`'s runtime-then-authored order; `ApplyTooltipText`'s wrap-width literal; `UpdateWorldHoverTooltip`/`TryBuildAndMountPopup` — the world-hover half added 2026-08-16); `src/AcDream.App/UI/Layout/ElementReader.cs` (`ElementInfo.TooltipText`'s own doc comment carries the same F3 correction); `src/AcDream.App/UI/UiItemSlot.cs` (`TooltipTextResolve`, `GetTooltipText`, the hardcoded popup-locator constants); `src/AcDream.Core/Items/ClientObject.cs` (`GetTooltipDisplayName`); `src/AcDream.App/UI/CursorFeedbackController.cs` (the related #411 found-cursor fix, same round — see that row) | The 243 elements WITH literal text — the "core" case #409 ships — cover every hover-text scenario the investigation's own landmark checks exercised (main-game-UI Appearance-page rotate/color/spin hints, etc.). F9 correction: "243 with literal text" is not automatically "243 showable" — `RetailTooltipPresenter.OnTooltipShow`'s real gate is the FULL conjunction of `TooltipEnabled` (P0x4B) AND non-null text (P0x49) AND both popup-locator ids (P0x47/P0x48) — so this was measured, not assumed: `TooltipLiveDatTests.ClientWideSweep_FindsKnownLandmarksAndAFloorCount`'s `Showable` column finds the intersection is exactly 243, i.e. every element authoring literal text also authors the other three properties together (they are evidently authored as one group in practice). The P0x3D sweep found zero authoring elements, so the unconditional display-width fallback is not an approximation for any element that exists today. | If a future DAT revision adds a `P0xD0`-truncated text element, a game-code `SetTooltip` caller, or authors a `P0x3D` override, it silently shows no tooltip / wraps at the wrong width instead of erroring — indistinguishable from "the element authors no tooltip at all" without re-running the sweep AND separately auditing which of the 187 no-literal-text elements would actually truncate at their authored width. | `UIElement::InqProperty @0x004638D0` (base authored-bag read, NOT a dynamic override); `UIElement::StartTooltipAtMouse @0x00460D70` (`m_TTText`-vs-`InqProperty` preference order); `UIElement_Text::RecalculateTruncation @0x00466F80` (`P0xD0` gate, `SetTooltip`/`ClearTooltip` sites); `UIElement_Text::InqSizewMargins @0x00469660` (`UITS_MAX_WIDTH` branch, `GetAttribute_Int(this, 0x3D, ...)`) | | TS-84 | Chargen 3D preview (Campaign CC slice CC6a foundation): `ChargenClothingTable`'s composer skips retail's ~8-branch Setup-id substitution chain (`ClothingTable::BuildObjDesc @ 0x005A7900`'s Umbraen/Penumbraen/Undead/Anakshay fallback) when a garment's `ClothingBaseEffects` has no entry for the resolved body Setup. MEASURED (not assumed) against the installed EoR dat across all 26 heritage/gender combinations via `ChargenAppearanceCatalogInstalledDatTests`, with the measurement now PINNED by a real assertion rather than diagnostic-only output (review fix round F7): the 9 standard heritages whose UI actually shows clothing controls resolve every default gear choice with zero coverage gaps. Undead is a real gap — its default gear choices (both genders) have NO base-effect entry on **ALL FOUR clothing slots — headgear, trousers, shirt, AND footwear** (not the three-slot "headgear/trousers/footwear" this row originally understated, with a self-contradicting "4 of 4 non-shirt slots" aside — corrected at the review fix round F2) — for Undead's own live body Setup (male 0x02001A9C / female 0x02001AA0), because that Setup is one of the skeleton/zombie variants the un-ported chain exists to redirect. The four measured missing clothing-table ids are identical on both genders and in a fixed order: `0x10000009, 0x100000F9, 0x10000001, 0x10000007` (Headgear, Trousers, Shirt, Footwear — the factory's own composition order). Gear Knight and both Olthoi variants also show gaps under a synthetic "select every offered option" sweep, but retail hides the clothing controls entirely for those three heritages (`gmCGAppearancePage::Update @ 0x0047E8F0`'s `m_pClothesButton->SetVisible(0)` branches for `mHeritageGroup == 6` and `== 0xc \|\| == 0xd`), so a real chargen selection never reaches them — not a live gap. | `src/AcDream.Core/CharGen/ChargenClothingTable.cs`; `src/AcDream.Core/CharGen/ChargenAppearanceFactory.cs` (`ComposeClothingSlot`) | CC6a is explicitly the rendering-foundation slice (index→ObjDesc factory + static-pose offscreen renderer, no page mount yet); porting the ~8-branch substitution chain is bounded follow-up work once CC6b wires real clothing-slot UI, not a blocker for the foundation deliverable — and the installed-DAT test proves the gap is narrow (one heritage, all four of ITS slots) rather than pervasive. | Undead's default clothing preview renders the bare body mesh for ALL FOUR slots — headgear, trousers, shirt, AND footwear (no clothing part/texture override applied on any of them, though the dye subpalette contribution — gated on a DIFFERENT lookup — is unaffected) — until the chain, or an equivalent per-heritage default-clothing-Setup map, is ported. | `ClothingTable::BuildObjDesc @ 0x005A7900` (Umbraen/Penumbraen/Undead/Anakshay Setup-substitution branches); `gmCGAppearancePage::Update @ 0x0047E8F0` (clothes-button visibility gate); `tests/AcDream.Content.Tests/CharGen/ChargenAppearanceCatalogInstalledDatTests.cs` | | TS-73 | **NARROWED 2026-08-11 at Campaign OP slice OP4.** `RuntimeCharacterOptionsState.TrySetOption`'s port of `CPlayerModule::OnChanged @0x0059A8E0`'s local side-effect switch (step 2) still covers only the two `PlayerModule`-state-mutating cases (`case 2`/`case 0x12` fellowship mutual exclusion) — that part is unchanged. Of the four presentation-binding cases, TWO are now closed: `0x07 ViewCombatTarget` (re-pointed `ICombatGameplaySettingsSource` reads `RuntimeCharacterOptionsState` live — `CharacterOptionCombatSettingsSource`, `src/AcDream.App/Combat/LiveCombatAttackOperations.cs`) and `0x30 DisableDistanceFog` (`WeatherSystem.DisableDistanceFogSource`, a poll bound once in `GameWindow.cs`, forces `FogMode.Off` in `WeatherSystem.Snapshot`) — NEITHER lives inside `TrySetOption`'s own switch; both are separate App-layer poll bindings, so the literal claim in this row's title ("this Runtime-only seam can reach") stays true, but the user-observable symptom is fixed for these two ids. The remaining two, `0x04 DisableMostWeatherEffects` and `0x05 PersistentAtDay`, stay open — see TS-6 (weather-particle subsystem not yet located) and TS-75 (day/night force) respectively; this row no longer duplicates either. | `src/AcDream.Runtime/Gameplay/RuntimeCharacterState.cs` (`RuntimeCharacterOptionsState.TrySetOption`) | The remaining two options are correctly scoped to their OWN pre-existing/new rows (TS-6, TS-75) rather than re-litigated here. | Toggling `DisableMostWeatherEffects`/`PersistentAtDay` writes the bit and dirties/auto-saves it correctly, but produces NONE of retail's immediate local presentation change (weather doesn't stop, day/night doesn't force) — see TS-6/TS-75 for why. `ViewCombatTarget`/`DisableDistanceFog` are retired from this row's risk: both now behave correctly. | `CPlayerModule::OnChanged @0x0059A8E0`; `docs/research/2026-08-10-character-options-map.md` §1.5 | | TS-75 | "Always Daylight Outdoors" (`PlayerOption PersistentAtDay`, `CPlayerModule::OnChanged` case `0x05` → `LScape::SetDay(value)`) has no acdream consumer. The campaign plan's own Group-B binding table cites `RuntimeWorldEnvironmentDefinition.ForcedDayGroupIndex` as the target seam — **that citation is a mechanism mismatch, corrected here**: `ForcedDayGroupIndex` selects which WEATHER-VARIETY day-group (`RuntimeWorldDayGroupDefinition`, e.g. a Clear/Overcast/Rain/Snow/Storm pick) is always chosen — the SAME deterministic-per-day-RNG mechanism `WeatherSystem`'s own roll uses (see TS-6) — NOT retail's time-of-day day/night force. No acdream mechanism currently overrides the sky cycle's TIME to stay in daytime lighting; wiring this option correctly needs that mechanism built first, not just a poll into the wrong field. | `src/AcDream.Runtime/World/RuntimeWorldEnvironmentState.cs` (`RuntimeWorldEnvironmentDefinition.ForcedDayGroupIndex` — NOT the right target); no current consumer exists | Filed rather than silently wired to the wrong field — a poll into `ForcedDayGroupIndex` would have SILENTLY changed the character's weather-variety odds instead of forcing daytime, an incorrect fix masquerading as a correct one (CLAUDE.md's "no workarounds" rule). | Toggling the option writes the bit and dirties/auto-saves it correctly, but night still falls normally — no observable daylight-forcing behavior. | `CPlayerModule::OnChanged @0x0059A8E0` case 5; `LScape::SetDay` (not yet located in the decomp) |