From 9d9280a069469697a4a8b98d8bcd8a6b8222eab1 Mon Sep 17 00:00:00 2001 From: Erik Date: Mon, 17 Aug 2026 08:49:11 +0200 Subject: [PATCH] =?UTF-8?q?fix(ui):=20morning=20gate=20=E2=80=94=20world?= =?UTF-8?q?=20tooltips=20ride=20retail's=20mouse-idle=20dwell,=20not=20the?= =?UTF-8?q?=20found=20edge?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User finding 1 (side-by-side vs retail): our world-object tooltips popped the instant the found object changed; retail's "lag". The night round's derivation from RecvNotice_SmartBoxObjectFound @0x004E5AD0 misread the notice as edge-MOUNTING: its immediate StartTooltipAtMouse @0x004E5DFB is inside `if (s_pInstance->m_dragElement != 0)` (@0x004E5D8E) — and m_dragElement is a real, distinct PDB field in acclient.h's UIElementManager (separate from the m_pTooltipElement family), so the immediate mount is DRAG-AND-DROP ONLY. The ordinary hover path merely STAGES the name (SetTooltip @0x004E5D74 + the |=0x20 TooltipOn bit) and the display rides the SAME UIElementManager::CheckTooltip @0x0045B6E0 mouse-idle dwell as UI tooltips: 250 ms (m_tooltipDelay @0x0045f75d) since m_lastMouseMoveTime (stamped on EVERY move, MouseMoveHandler @0x0045e736). Found swaps under an IDLE mouse replace the popup the same frame (SetTooltip's own text-change teardown @0x004617FF -> ResetTooltip @0x0045C360 tail-calling CheckTooltip); the 10 s duration expiry (@0x0045b78a) requires a fresh mouse move before re-arming (SwitchMouseOver(null) @0x0045b7b2 clears m_pElementLastEntered). Port: UiRoot gains the unconditional last-mouse-move stamp (m_lastMouseMoveTime 1:1 — the existing _hoverStartedMs stamps are deliberately conditional) exposed as MouseIdleMs/NowMs; RetailTooltipPresenter.UpdateWorldHoverTooltip now stages text at the notice edge (ShowTooltips gate + name resolve read there, @0x004E5D21/ @0x004E5D3B, empty-name SetTooltip skip @0x004E5D48 included) and mounts via the CheckTooltip dwell block (no-capture gate @0x0045b715, m_tooltipEnable via MouseHover @0x0046254C — which the drag-immediate branch faithfully bypasses). Session reset also forgets the staged text. Tests: the world-hover fixture section rewritten to the corrected model — found edge stages but never mounts before the dwell; a continuously moving mouse never mounts until it rests; idle found-swap replaces same-frame without stacking; duration auto-hide needs a move + fresh dwell to remount; drag-in-progress mounts immediately. 38/38 pass. Register TS-85 and ISSUES item 2 corrected honestly: the "edge-fired (no dwell)" conclusion is superseded by the user's retail evidence and the m_dragElement branch read. Co-Authored-By: Claude Fable 5 --- docs/ISSUES.md | 28 +- .../retail-divergence-register.md | 2 +- .../UI/Layout/RetailTooltipPresenter.cs | 216 +++++++++++--- src/AcDream.App/UI/UiRoot.cs | 29 ++ .../UI/Layout/RetailTooltipPresenterTests.cs | 277 ++++++++++++++---- 5 files changed, 444 insertions(+), 108 deletions(-) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 65528fcf..ff8429be 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -630,11 +630,28 @@ called out separately. own `Label`. 2. **World-object hover tooltip (NPCs, players, signs, chests, portals) — - SHIPPED.** NOT the UI-element dwell-timer path — retail's mechanism is + SHIPPED; TIMING CORRECTED at the 2026-08-17 morning gate round.** 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 + using the current mouse position regardless of input focus. **The + original "fires IMMEDIATELY (no dwell wait)" reading here was a misread + — the user's side-by-side retail comparison (retail world tooltips "lag"; + ours popped instantly) sent the derivation back, and the notice's + immediate `StartTooltipAtMouse @0x004E5DFB` turned out to sit inside + `if (UIElementManager::s_pInstance->m_dragElement != 0)` (`@0x004E5D8E` + — a real, distinct PDB field, drag-and-drop only). The ordinary hover + path STAGES the name (`SetTooltip @0x004E5D74` + the `|= 0x20` TooltipOn + bit) and the display rides the SAME `UIElementManager::CheckTooltip + @0x0045B6E0` mouse-idle dwell as UI-element tooltips: 250 ms + (`m_tooltipDelay @0x0045f75d`) since the last mouse move + (`m_lastMouseMoveTime`, stamped on EVERY move `@0x0045e736`), so a + continuously moving mouse shows nothing and the popup appears only once + the cursor rests. Found-object changes under an IDLE mouse swap the + popup the same frame (`SetTooltip`'s text-change teardown `@0x004617FF` + → `ResetTooltip @0x0045C360` tail-calls `CheckTooltip`); the 10 s + duration expiry requires a fresh mouse move before re-arming + (`SwitchMouseOver(null) @0x0045b7b2`).** 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 @@ -695,8 +712,9 @@ called out separately. 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. +tooltip should appear after the 250 ms idle dwell (mouse must REST; +sweeping continuously shows nothing — corrected 2026-08-17) if "Show +Tooltips" is on; hover a sign/chest/portal similarly. **2026-08-16/17 overnight hover/UI round, Batch A bug 1 — CLOSED same round: world tooltips never cleared, stacking dozens of popups.** The world-object diff --git a/docs/architecture/retail-divergence-register.md b/docs/architecture/retail-divergence-register.md index e4fc67c5..b50246a9 100644 --- a/docs/architecture/retail-divergence-register.md +++ b/docs/architecture/retail-divergence-register.md @@ -412,7 +412,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. **F12 correction (night-round review, 2026-08-17): this is 17 sites, not 15** — the original tally dropped `gmPaperDollUI::UpdateItemSlotTooltip @0x004A52EF` (mentioned two sentences below as its own closed row) and undercounted by one more besides. The 17 `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. **BATCH B (2026-08-17) CLOSED the spellcasting and character-panel rows of this list. BATCH C (2026-08-17, Map/House toolbar panel) CLOSES THE LAST REMAINING ITEM: `gmMapUI::AddMapNote @0x004A1C51`'s 53 town-hotspot tooltips are now ported via `MapPageController.BuildTownMarkers` (`src/AcDream.App/UI/Layout/MapPageController.cs`), setting `UiButton.TooltipText` (retail's RUNTIME `m_TTText`/`SetTooltip` mechanism, not the DAT-authored `P0x49` path an earlier same-day cut mistakenly used and which never rendered live during verification) plus a hardcoded `AuthoredTooltipRootElementId`/`AuthoredTooltipLayoutDid` pointing at the same shared popup skin `UiItemSlot` already uses (`0x10000395`/`0x21000041`), since the town-marker template authors no locator of its own; verified live post-fix (hovering Aerlinthe Island renders its tooltip correctly) — literal town names from `MapLocations.cs` (a verbatim port of `s_rgLocations`), not a DAT string-table lookup, matching `AddMapNote`'s own `StringInfo::SetLiteralValue` call. Sub-mechanism (1)'s `SetTooltip`-call-site enumeration is 16 of 17 known sites PORTED — `UIElement_Text::RecalculateTruncation @0x00466F80` (the headline, highest-volume site named at the top of sub-mechanism (1)) remains the ONE open item, exactly as this row's own sub-mechanism (1) text above already scoped it out (its own "Sized as genuinely disproportionate... deferred here" note). The prior "all 15 known sites accounted for" close (F12 correction, night-round review) was wrong twice over: the count is 17, not 15, and RecalculateTruncation was never actually ported — it was always the one deliberately-deferred item, not a closed one.** Batch B audit findings: the endowment icon `@0x004C63A1`, favorite `@0x004C7206`, and submenu `@0x004C67D8` sites turned out to be ALREADY CORRECT — all three are `UiCatalogSlot`-based and the pre-existing `Label`-driven `GetTooltipText` already carried retail's exact text (`SpellCastSubMenu::AddFavorite @0x004C7060`/`UpdateFromPlayerModule @0x004C6570` both build a single-arg `Formatted` PStringBase — plain spell name, no wrapper — for the favorite-bar/submenu case; `gmSpellcastingUI::UpdateEndowmentIcon @0x004C6120` mirrors the cast button's confirmed `"%s (%hs)"` literal at `data_7b64d8` — item name, then spell name in parens — via the identical two-value narrow/wide prep sequence, one address away in the same function family). The cast button `@0x004C6FE8`/`ClearTooltip @0x004C6AAE` was the one real gap (`UiButton` had no tooltip wiring at all): now ported via `SpellcastingUiController.UpdateCastAvailability`/`ComputeEndowmentCastState`, sourced from `gmSpellcastingUI::UpdateCastButtonTooltip @0x004C6A30`. Fully verified literal text: the no-selection states (`"Select a spell to cast"` @ `data_7b64ec`, `"You have no spells ready to cast"` @ `data_7b6520`) and the complete endowment-item branch (`"USE the %s"` @ `data_7b64c0`, `" on %s"` @ `data_7b6464`, `"You must select a target for the %s"` @ `data_7b6478`; `ItemUses::IsUseable_SelfTarget @0x004fcd30` is exactly `ItemUseability.AllowsSelfTarget`). NOT ported: the endowment branch's incompatible-target sub-state (`"You must select an appropriate\ntarget for the %s"` @ `data_7b6400`, gated by `ItemHolder::TargetCompatibleWithObject @0x00587520` — a ~400-line function with its own chat-message side effects, out of scope for a tooltip batch; a present target is optimistically treated as compatible, same text as the confirmed-compatible case). **CORRECTED at the night-round review (F3/F4, 2026-08-17): the plain-spell branch's wording is NOT unrecoverable — the "genuine `gmNoticeHandler` vtable SLOTS" claim above was itself the artifact. `PStringBase::sprintf`'s second argument at those three call sites is a raw pushed literal (a plain `push 0x7bXXXX; call sprintf`); Binary Ninja's pseudo-C rendering of that operand as `&gmSpellcastingUI::\`vftable'.RecvNotice_XXX` was a spurious symbol match, not the true operand — a direct capstone disassembly of the raw bytes at `0x4c6e48`/`0x4c6ea4`/`0x4c6f18`/`0x4c6f5d` resolves the actual constants: `"CAST %hs"` @0x7b63a4 (untargeted/self-cast at `0x4c6f35`, and targeted+compatible at `0x4c6e57` — both enabled, the latter appending `" on %s"` @0x7b6464 with the target's name), `"You must select an appropriate target for %hs"` @0x7b6348 (targeted+incompatible, disabled), `"You must select a target for %hs"` @0x7b63b8 (no target, disabled); `%hs` is the spell's own name in all four call sites (`CSpellBase::InqName`, the same call `0x5bbee0` throughout). Now ported: `RuntimeSpellCastState.EvaluateCastGate` (the four-state gate) + `SpellcastingUiController.ComputeSpellCastState`. Also corrected the endowment branch's "USE the %s" operand: it was NOT the bare item name (F4) — the vararg to `"USE the %s"`/`"You must select a target for the %s"`/the still-unported incompatible-target string is the SAME composed `"%s (%hs)"` string (item name, spell name) built once at `@0x004c6bb6-ef` from format literal `data_7b64d8`, byte-confirmed by all three sprintf call sites (`0x4c6c7f`/`0x4c6ca4`/`0x4c6d46`) reading the identical `[esp+0x18]` slot — now ported via `SpellcastingUiController.ComposeEndowmentName`.** The character-panel `AttributeInfoRegion @0x004F1617` / `Attribute2ndInfoRegion @0x004F1777` / `SkillInfoRegion @0x004F222F` constructors are now fully ported through a new `UiClickablePanel.TooltipText` (the same settable-string seam as `UiButton.TooltipText`): the six hardcoded attribute descriptions (`SkillSystem::InqAttributeDescription @0x005c8e30`) and three hardcoded, pair-shared vitals descriptions (`SkillSystem::InqAttribute2ndDescription @0x005c8f70`) were byte-decoded from the retail string pool (the pseudo-C dump truncates them with "…"); skill tooltips compose `SkillInfoRegion::GetTooltip @0x004f1fe0`'s exact `"\n" + formula + description` (ported verbatim, including the confirmed lack of any separator between the formula and description text) from the ALREADY-DAT-parsed `DatReaderWriter.Types.SkillBase.Description`/`.Formula` fields (portal `0x0E000004`, the same resource `CharacterSheetProvider.SkillTable` already reads for skill names/costs) rather than hand-transcribed literals — no guessing was needed for the ~30+ skill description strings. The formula-to-text algorithm itself (`SkillSystem::InqSkillFormula @0x005c89b0`, e.g. producing `"( (Strength + Coordination) / 2 )"`) was fully recovered by byte-decoding six short literal fragments (`data_7e7930`/`7e7934`/`7e7940`/`7e7950`/`7e7954`/`797584`) the pseudo-C dump left completely unlabeled — they sit between two `gmSpellcastingUI` vtable declarations and Binary Ninja's type inference never recognized them as strings, so the raw hex had to be read directly as narrow ASCII (confirmed against the function's own directly-visible `" / %u"` and `"(%u x %s)"` literals, which needed no such recovery). 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); Batch B (2026-08-17) additions: `src/AcDream.App/UI/UiPanel.cs` (`UiClickablePanel.TooltipText`/`GetTooltipText`); `src/AcDream.App/UI/Layout/SpellcastingUiController.cs` (`UpdateCastAvailability`, `ComputeEndowmentCastState`); night-round review (F3/F4, 2026-08-17) additions: `src/AcDream.App/UI/Layout/SpellcastingUiController.cs` (`ComputeSpellCastState`, `ComposeEndowmentName`); `src/AcDream.Runtime/Gameplay/RuntimeSpellCastState.cs` (`EvaluateCastGate`, `SpellCastGate`); `src/AcDream.App/Net/RetailSkillFormula.cs` (`AttributeName`, `FormatFormula`, `BuildTooltip`); `src/AcDream.App/UI/Layout/CharacterSheet.cs` (`CharacterSkill.TooltipText`); `src/AcDream.App/UI/Layout/CharacterSheetProvider.cs` (`BuildLiveCharacterSkills`'s tooltip compose); `src/AcDream.App/UI/Layout/CharacterStatController.cs` (`AttributeDescriptions`, `Attribute2ndDescriptions`, `BuildAttributeRows`/`BuildSkillRows` row wiring) | 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, ...)`); Batch B (2026-08-17): `gmSpellcastingUI::UpdateCastButtonTooltip @0x004C6A30` (cast-button state machine); `gmSpellcastingUI::UpdateEndowmentIcon @0x004C6120` (endowment-icon `"%s (%hs)"` confirmation); `SpellCastSubMenu::AddFavorite @0x004C7060` / `UpdateFromPlayerModule @0x004C6570` (favorite/submenu plain-name confirmation); `ItemUses::IsUseable_SelfTarget @0x004fcd30`; `AttributeInfoRegion::AttributeInfoRegion @0x004f1530` / `Attribute2ndInfoRegion::Attribute2ndInfoRegion @0x004f1680` / `SkillInfoRegion::SkillInfoRegion @0x004f2140` / `SkillInfoRegion::GetTooltip @0x004f1fe0`; `SkillSystem::InqAttributeName @0x005c8d90` / `InqAttributeDescription @0x005c8e30` / `InqAttribute2ndName @0x005c8ed0` / `InqAttribute2ndDescription @0x005c8f70` / `InqSkillFormula @0x005c89b0` | +| 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. **F12 correction (night-round review, 2026-08-17): this is 17 sites, not 15** — the original tally dropped `gmPaperDollUI::UpdateItemSlotTooltip @0x004A52EF` (mentioned two sentences below as its own closed row) and undercounted by one more besides. The 17 `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 `PlayerModule::ShowTooltips`-gated, `GetAppropriateName`-only (no stack prefix — a real, decomp-confirmed asymmetry vs. the item-cell case) trigger — **TIMING CORRECTED at the 2026-08-17 morning gate round (user finding: retail world tooltips "lag"; ours popped instantly): the original "edge-fired (no dwell)" reading was a misread — the notice's immediate `StartTooltipAtMouse @0x004E5DFB` sits inside `if (s_pInstance->m_dragElement != 0)` (`@0x004E5D8E`; `m_dragElement` is a real, distinct PDB field in `acclient.h`'s `UIElementManager`, separate from the `m_pTooltipElement` family), so the immediate mount is DRAG-ONLY; the ordinary hover path merely STAGES the name (`SetTooltip @0x004E5D74` + `|= 0x20`) and the display rides `CheckTooltip @0x0045B6E0`'s mouse-idle dwell (`m_lastMouseMoveTime` stamped on EVERY move `@0x0045e736` + `m_tooltipDelay` 0.25 s `@0x0045f75d`), with found-object changes under an idle mouse swapping the popup same-frame via `SetTooltip`'s own text-change teardown (`@0x004617FF` → `ResetTooltip @0x0045C360` tail-calling `CheckTooltip`) and the 10 s `m_tooltipDuration` expiry requiring a fresh mouse move before re-arming (`SwitchMouseOver(null) @0x0045b7b2`) — all now ported, including the drag-immediate branch**, 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. **BATCH B (2026-08-17) CLOSED the spellcasting and character-panel rows of this list. BATCH C (2026-08-17, Map/House toolbar panel) CLOSES THE LAST REMAINING ITEM: `gmMapUI::AddMapNote @0x004A1C51`'s 53 town-hotspot tooltips are now ported via `MapPageController.BuildTownMarkers` (`src/AcDream.App/UI/Layout/MapPageController.cs`), setting `UiButton.TooltipText` (retail's RUNTIME `m_TTText`/`SetTooltip` mechanism, not the DAT-authored `P0x49` path an earlier same-day cut mistakenly used and which never rendered live during verification) plus a hardcoded `AuthoredTooltipRootElementId`/`AuthoredTooltipLayoutDid` pointing at the same shared popup skin `UiItemSlot` already uses (`0x10000395`/`0x21000041`), since the town-marker template authors no locator of its own; verified live post-fix (hovering Aerlinthe Island renders its tooltip correctly) — literal town names from `MapLocations.cs` (a verbatim port of `s_rgLocations`), not a DAT string-table lookup, matching `AddMapNote`'s own `StringInfo::SetLiteralValue` call. Sub-mechanism (1)'s `SetTooltip`-call-site enumeration is 16 of 17 known sites PORTED — `UIElement_Text::RecalculateTruncation @0x00466F80` (the headline, highest-volume site named at the top of sub-mechanism (1)) remains the ONE open item, exactly as this row's own sub-mechanism (1) text above already scoped it out (its own "Sized as genuinely disproportionate... deferred here" note). The prior "all 15 known sites accounted for" close (F12 correction, night-round review) was wrong twice over: the count is 17, not 15, and RecalculateTruncation was never actually ported — it was always the one deliberately-deferred item, not a closed one.** Batch B audit findings: the endowment icon `@0x004C63A1`, favorite `@0x004C7206`, and submenu `@0x004C67D8` sites turned out to be ALREADY CORRECT — all three are `UiCatalogSlot`-based and the pre-existing `Label`-driven `GetTooltipText` already carried retail's exact text (`SpellCastSubMenu::AddFavorite @0x004C7060`/`UpdateFromPlayerModule @0x004C6570` both build a single-arg `Formatted` PStringBase — plain spell name, no wrapper — for the favorite-bar/submenu case; `gmSpellcastingUI::UpdateEndowmentIcon @0x004C6120` mirrors the cast button's confirmed `"%s (%hs)"` literal at `data_7b64d8` — item name, then spell name in parens — via the identical two-value narrow/wide prep sequence, one address away in the same function family). The cast button `@0x004C6FE8`/`ClearTooltip @0x004C6AAE` was the one real gap (`UiButton` had no tooltip wiring at all): now ported via `SpellcastingUiController.UpdateCastAvailability`/`ComputeEndowmentCastState`, sourced from `gmSpellcastingUI::UpdateCastButtonTooltip @0x004C6A30`. Fully verified literal text: the no-selection states (`"Select a spell to cast"` @ `data_7b64ec`, `"You have no spells ready to cast"` @ `data_7b6520`) and the complete endowment-item branch (`"USE the %s"` @ `data_7b64c0`, `" on %s"` @ `data_7b6464`, `"You must select a target for the %s"` @ `data_7b6478`; `ItemUses::IsUseable_SelfTarget @0x004fcd30` is exactly `ItemUseability.AllowsSelfTarget`). NOT ported: the endowment branch's incompatible-target sub-state (`"You must select an appropriate\ntarget for the %s"` @ `data_7b6400`, gated by `ItemHolder::TargetCompatibleWithObject @0x00587520` — a ~400-line function with its own chat-message side effects, out of scope for a tooltip batch; a present target is optimistically treated as compatible, same text as the confirmed-compatible case). **CORRECTED at the night-round review (F3/F4, 2026-08-17): the plain-spell branch's wording is NOT unrecoverable — the "genuine `gmNoticeHandler` vtable SLOTS" claim above was itself the artifact. `PStringBase::sprintf`'s second argument at those three call sites is a raw pushed literal (a plain `push 0x7bXXXX; call sprintf`); Binary Ninja's pseudo-C rendering of that operand as `&gmSpellcastingUI::\`vftable'.RecvNotice_XXX` was a spurious symbol match, not the true operand — a direct capstone disassembly of the raw bytes at `0x4c6e48`/`0x4c6ea4`/`0x4c6f18`/`0x4c6f5d` resolves the actual constants: `"CAST %hs"` @0x7b63a4 (untargeted/self-cast at `0x4c6f35`, and targeted+compatible at `0x4c6e57` — both enabled, the latter appending `" on %s"` @0x7b6464 with the target's name), `"You must select an appropriate target for %hs"` @0x7b6348 (targeted+incompatible, disabled), `"You must select a target for %hs"` @0x7b63b8 (no target, disabled); `%hs` is the spell's own name in all four call sites (`CSpellBase::InqName`, the same call `0x5bbee0` throughout). Now ported: `RuntimeSpellCastState.EvaluateCastGate` (the four-state gate) + `SpellcastingUiController.ComputeSpellCastState`. Also corrected the endowment branch's "USE the %s" operand: it was NOT the bare item name (F4) — the vararg to `"USE the %s"`/`"You must select a target for the %s"`/the still-unported incompatible-target string is the SAME composed `"%s (%hs)"` string (item name, spell name) built once at `@0x004c6bb6-ef` from format literal `data_7b64d8`, byte-confirmed by all three sprintf call sites (`0x4c6c7f`/`0x4c6ca4`/`0x4c6d46`) reading the identical `[esp+0x18]` slot — now ported via `SpellcastingUiController.ComposeEndowmentName`.** The character-panel `AttributeInfoRegion @0x004F1617` / `Attribute2ndInfoRegion @0x004F1777` / `SkillInfoRegion @0x004F222F` constructors are now fully ported through a new `UiClickablePanel.TooltipText` (the same settable-string seam as `UiButton.TooltipText`): the six hardcoded attribute descriptions (`SkillSystem::InqAttributeDescription @0x005c8e30`) and three hardcoded, pair-shared vitals descriptions (`SkillSystem::InqAttribute2ndDescription @0x005c8f70`) were byte-decoded from the retail string pool (the pseudo-C dump truncates them with "…"); skill tooltips compose `SkillInfoRegion::GetTooltip @0x004f1fe0`'s exact `"\n" + formula + description` (ported verbatim, including the confirmed lack of any separator between the formula and description text) from the ALREADY-DAT-parsed `DatReaderWriter.Types.SkillBase.Description`/`.Formula` fields (portal `0x0E000004`, the same resource `CharacterSheetProvider.SkillTable` already reads for skill names/costs) rather than hand-transcribed literals — no guessing was needed for the ~30+ skill description strings. The formula-to-text algorithm itself (`SkillSystem::InqSkillFormula @0x005c89b0`, e.g. producing `"( (Strength + Coordination) / 2 )"`) was fully recovered by byte-decoding six short literal fragments (`data_7e7930`/`7e7934`/`7e7940`/`7e7950`/`7e7954`/`797584`) the pseudo-C dump left completely unlabeled — they sit between two `gmSpellcastingUI` vtable declarations and Binary Ninja's type inference never recognized them as strings, so the raw hex had to be read directly as narrow ASCII (confirmed against the function's own directly-visible `" / %u"` and `"(%u x %s)"` literals, which needed no such recovery). 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); Batch B (2026-08-17) additions: `src/AcDream.App/UI/UiPanel.cs` (`UiClickablePanel.TooltipText`/`GetTooltipText`); `src/AcDream.App/UI/Layout/SpellcastingUiController.cs` (`UpdateCastAvailability`, `ComputeEndowmentCastState`); night-round review (F3/F4, 2026-08-17) additions: `src/AcDream.App/UI/Layout/SpellcastingUiController.cs` (`ComputeSpellCastState`, `ComposeEndowmentName`); `src/AcDream.Runtime/Gameplay/RuntimeSpellCastState.cs` (`EvaluateCastGate`, `SpellCastGate`); `src/AcDream.App/Net/RetailSkillFormula.cs` (`AttributeName`, `FormatFormula`, `BuildTooltip`); `src/AcDream.App/UI/Layout/CharacterSheet.cs` (`CharacterSkill.TooltipText`); `src/AcDream.App/UI/Layout/CharacterSheetProvider.cs` (`BuildLiveCharacterSkills`'s tooltip compose); `src/AcDream.App/UI/Layout/CharacterStatController.cs` (`AttributeDescriptions`, `Attribute2ndDescriptions`, `BuildAttributeRows`/`BuildSkillRows` row wiring) | 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, ...)`); Batch B (2026-08-17): `gmSpellcastingUI::UpdateCastButtonTooltip @0x004C6A30` (cast-button state machine); `gmSpellcastingUI::UpdateEndowmentIcon @0x004C6120` (endowment-icon `"%s (%hs)"` confirmation); `SpellCastSubMenu::AddFavorite @0x004C7060` / `UpdateFromPlayerModule @0x004C6570` (favorite/submenu plain-name confirmation); `ItemUses::IsUseable_SelfTarget @0x004fcd30`; `AttributeInfoRegion::AttributeInfoRegion @0x004f1530` / `Attribute2ndInfoRegion::Attribute2ndInfoRegion @0x004f1680` / `SkillInfoRegion::SkillInfoRegion @0x004f2140` / `SkillInfoRegion::GetTooltip @0x004f1fe0`; `SkillSystem::InqAttributeName @0x005c8d90` / `InqAttributeDescription @0x005c8e30` / `InqAttribute2ndName @0x005c8ed0` / `InqAttribute2ndDescription @0x005c8f70` / `InqSkillFormula @0x005c89b0` | | 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) | diff --git a/src/AcDream.App/UI/Layout/RetailTooltipPresenter.cs b/src/AcDream.App/UI/Layout/RetailTooltipPresenter.cs index 5d2360cf..c98b1699 100644 --- a/src/AcDream.App/UI/Layout/RetailTooltipPresenter.cs +++ b/src/AcDream.App/UI/Layout/RetailTooltipPresenter.cs @@ -287,15 +287,42 @@ public sealed class RetailTooltipPresenter : IDisposable // ── World-object hover tooltip (docs/ISSUES.md #409 follow-on) ───────── // // Port of UIElement_SmartBoxWrapper::RecvNotice_SmartBoxObjectFound - // @0x004E5AD0's tooltip half (@0x004E5D13-@0x004E5E00). Unlike the - // dwell-timer UI-element path above, this trigger is EDGE-fired: retail - // calls SetTooltip + StartTooltipAtMouse IMMEDIATELY when SmartBox's - // found-object id CHANGES (@0x004E5D74/@0x004E5DFB) — no dwell wait — - // gated per-edge by PlayerModule::ShowTooltips (@0x004E5D21, - // CharacterOptionId.ShowTooltips in this port's CharacterOptionTable). - // The text is ACCWeenieObject::GetObjectName(id, NAME_APPROPRIATE, 0) - // (@0x004E5D3B) — the SAME call UIElement_UIItem::UpdateTooltip uses, - // but WITHOUT that item-cell's separate stack-count "%d %s" prefix + // @0x004E5AD0's tooltip half (@0x004E5D13-@0x004E5E00), CORRECTED at the + // 2026-08-17 morning gate round (user finding 1: our world tooltips + // popped instantly; retail's "lag"). The night round misread the notice + // as edge-MOUNTING ("SetTooltip + StartTooltipAtMouse IMMEDIATELY ... no + // dwell wait"): the immediate StartTooltipAtMouse @0x004E5DFB is inside + // `if (UIElementManager::s_pInstance->m_dragElement != 0)` (@0x004E5D8E) + // — m_dragElement is a real, distinct PDB field (acclient.h's + // UIElementManager, separate from the m_pTooltipElement family), so the + // immediate mount fires ONLY while a drag-and-drop is in progress + // ("what am I about to drop this on"). In the ordinary hover case the + // notice merely STAGES the name (UIElement::SetTooltip @0x004E5D74 + + // `|= 0x20` TooltipOn @0x004E5D79) on the wrapper, and the DISPLAY rides + // the standard per-frame dwell machinery: + // + // UIElementManager::CheckTooltip @0x0045B6E0 (per frame, hover not + // started): mouse idle since m_lastMouseMoveTime (stamped on EVERY + // move, MouseMoveHandler @0x0045e736) for >= m_tooltipDelay (0.25 s + // default @0x0045f75d; the runtime-constructed wrapper authors no + // P0x50 override) while entered over the wrapper with no capture + // (@0x0045b715) -> StartHover @0x00459250 -> the wrapper's inherited + // UIElement::MouseHover @0x00462520 (TooltipOn bit + m_tooltipEnable) + // -> StartTooltipAtMouse reads the staged m_TTText -> popup mounts. + // + // Found-object CHANGES while a popup is up tear it down via SetTooltip's + // OWN text-change teardown (@0x004617FF: owner == this && popup != null + // -> ResetTooltip @0x0045C360, which tail-calls CheckTooltip) — so with + // an IDLE mouse the replacement popup mounts the SAME frame (the dwell + // deadline long passed), while a MOVING mouse keeps pushing the deadline + // out and shows nothing until it rests. found -> 0 stages EMPTY text + // (ClearTooltip @0x004E5E30 = SetTooltip(empty) @0x004625F9): the same + // teardown fires and nothing remounts. The ShowTooltips gate + // (PlayerModule::ShowTooltips @0x004E5D21, CharacterOptionId.ShowTooltips) + // and the name resolve (@0x004E5D3B) happen at the EDGE, exactly where + // retail reads them. The text is ACCWeenieObject::GetObjectName(id, + // NAME_APPROPRIATE, 0) — the SAME call UIElement_UIItem::UpdateTooltip + // uses, but WITHOUT that item-cell's separate stack-count "%d %s" prefix // (RecvNotice_SmartBoxObjectFound's own text-building block has no // count logic at all — a real, decomp-confirmed asymmetry versus // UiItemSlot's GetTooltipDisplayName). @@ -357,6 +384,31 @@ public sealed class RetailTooltipPresenter : IDisposable private uint _worldHoverGuid; private bool _worldTooltipShowing; + /// The wrapper's staged m_TTText — written at the + /// found-object EDGE (SetTooltip @0x004E5D74 / + /// ClearTooltip @0x004E5E30), displayed only when the dwell + /// machinery mounts it. Null/empty = cleared (retail's empty + /// StringInfo; StartTooltipAtMouse @0x00460DA3's + /// IsValid test fails and the wrapper authors no P0x49 + /// fallback, so nothing shows). + private string? _worldStagedText; + + /// When the world popup mounted — retail + /// m_tooltipStart, for the m_tooltipDuration (10 s) + /// auto-hide (CheckTooltip @0x0045b78a). + private long _worldTooltipShownMs; + + /// Set by the duration auto-hide: retail's expiry path calls + /// SwitchMouseOver(this, nullptr) @0x0045b7b2, clearing + /// m_pElementLastEntered — the dwell cannot re-arm until the next + /// mouse move re-enters the wrapper. Without this latch the port would + /// remount one frame after every auto-hide (staged text still present, + /// mouse still idle) in a 10 s flicker loop. + private bool _worldRearmRequiresMouseMove; + + private int _worldLastSeenMouseX = int.MinValue; + private int _worldLastSeenMouseY = int.MinValue; + /// /// The world-hover pick (retail's SmartBox::find_object via /// UIElement_SmartBoxWrapper::FindObject @0x004E5430's fallback @@ -392,50 +444,140 @@ public sealed class RetailTooltipPresenter : IDisposable if (WorldHoverGuidProvider is null) return; + // Post-auto-hide re-arm: retail's duration expiry ran + // SwitchMouseOver(null); the next real mouse move re-enters the + // wrapper and only THEN can the dwell restart (see the + // _worldRearmRequiresMouseMove field doc). + if (_host.MouseX != _worldLastSeenMouseX || _host.MouseY != _worldLastSeenMouseY) + { + _worldLastSeenMouseX = _host.MouseX; + _worldLastSeenMouseY = _host.MouseY; + _worldRearmRequiresMouseMove = false; + } + uint found = _host.Pick(_host.MouseX, _host.MouseY) is null ? WorldHoverGuidProvider() ?? 0u : 0u; - if (found == _worldHoverGuid) - return; // no change -> RecvNotice_SmartBoxObjectFound never re-fires - _worldHoverGuid = found; + // ── The notice edge (RecvNotice_SmartBoxObjectFound @0x004E5AD0's + // tooltip half) — STAGES text; mounts nothing except mid-drag. ── + if (found != _worldHoverGuid) + { + _worldHoverGuid = found; - // #409 follow-on (2026-08-16 overnight hover/UI round, Batch A bug 1): - // every found-object edge — whether to a DIFFERENT object or to - // none at all — tears down whatever world popup is currently up - // FIRST, mirroring OnTooltipShow's own unconditional RemovePopup() at - // its top. The pre-fix code only cleared on the found==0u edge, so an - // A-found-B transition (walking past a run of NPCs/doors/lifestones - // with never a frame of "nothing found" between them) called - // TryBuildAndMountPopup again with the OLD popup still mounted as a - // child of _host — only the _popupRoot reference got overwritten, so - // every previous popup was orphaned in the tree and never removed. - // _popupRoot is a single field by design (retail's own single - // m_pTooltipElement slot); this restores that single-slot invariant. + string? staged = _worldStagedText; + if (found == 0u || WorldTooltipsEnabled?.Invoke() != true) + { + // @0x004E5E2A/@0x004E5E30: bit &= ~0x20 + ClearTooltip. + staged = null; + } + else + { + string? name = WorldHoverNameResolver?.Invoke(found); + // @0x004E5D48: the empty-name guard skips SetTooltip + // entirely — the PREVIOUS staged text stays in place + // (retail's own shape; nameless found objects are rare). + if (!string.IsNullOrEmpty(name)) + staged = name; + } + + // UIElement::SetTooltip @0x004617C0: only a text CHANGE does + // anything (@0x004617D9's operator== guard). On change, the + // popup this surface currently shows is torn down + // (@0x004617FF ResetTooltip) — the dwell block below is + // ResetTooltip's tail-called CheckTooltip, re-run this same + // frame, so an IDLE mouse remounts the replacement immediately. + // + // #409 follow-on (2026-08-16 overnight hover/UI round, Batch A + // bug 1): this teardown must fire on EVERY staging edge — an + // A-found-B transition with no intervening "nothing found" + // frame previously orphaned each old popup in the tree + // (_popupRoot single-slot invariant, retail's own single + // m_pTooltipElement). + if (!string.Equals(staged, _worldStagedText, StringComparison.Ordinal)) + { + _worldStagedText = staged; + if (_worldTooltipShowing) + RemovePopup(); + + // The drag-in-progress exception @0x004E5D8E: m_dragElement + // != 0 -> ResetTooltip + StartTooltipAtMouse IMMEDIATELY + // (@0x004E5DF0/@0x004E5DFB), no dwell — while dragging an + // item over the world you see the drop target's name at + // once. NOT gated on m_tooltipEnable (this path bypasses + // UIElement::MouseHover entirely). + if (!string.IsNullOrEmpty(staged) && _host.DragSource is not null) + { + if (TryBuildAndMountPopup( + SharedPopupSkinRootElementId, SharedPopupSkinLayoutDid, staged!)) + { + _worldTooltipShowing = true; + _worldTooltipShownMs = _host.NowMs; + } + return; + } + } + } + + // ── CheckTooltip @0x0045B6E0, the wrapper's share of it. ── if (_worldTooltipShowing) - RemovePopup(); + { + // Auto-hide after m_tooltipDuration (@0x0045b78a; 10 s default + // @0x0045f767, UiRoot.TooltipDurationMs). The expiry path's + // SwitchMouseOver(null) @0x0045b7b2 means no remount until the + // mouse moves again. + if (_host.NowMs - _worldTooltipShownMs >= _host.TooltipDurationMs) + { + RemovePopup(); + _worldRearmRequiresMouseMove = true; + } + return; + } - if (found == 0u) + // StartTooltipAtMouse @0x00460DA3: empty staged m_TTText + no + // authored P0x49 on the runtime-constructed wrapper -> nothing. + if (string.IsNullOrEmpty(_worldStagedText)) return; - if (WorldTooltipsEnabled?.Invoke() != true) + // @0x0045b715: the arm branch requires no mouse capture. + if (_host.Captured is not null) return; - string? text = WorldHoverNameResolver?.Invoke(found); - if (string.IsNullOrEmpty(text)) + if (_worldRearmRequiresMouseMove) return; - // A UI-element popup cannot be showing here: UiRoot's own hover - // (queried above) is null whenever this branch runs, so its dwell - // timer never arms and OnTooltipShow never fires concurrently. - if (TryBuildAndMountPopup(SharedPopupSkinRootElementId, SharedPopupSkinLayoutDid, text)) + // @0x0045b747: mouse idle since m_lastMouseMoveTime for >= the + // global m_tooltipDelay (the wrapper authors no per-element P0x50). + if (_host.MouseIdleMs < _host.TooltipDelayMs) + return; + + // UIElement::MouseHover @0x0046254C's m_tooltipEnable gate — the + // dwell-mounted path IS gated on the global enable (unlike the + // drag-immediate branch above, which bypasses MouseHover). + if (!Enabled) + return; + + if (TryBuildAndMountPopup( + SharedPopupSkinRootElementId, SharedPopupSkinLayoutDid, _worldStagedText!)) + { _worldTooltipShowing = true; + _worldTooltipShownMs = _host.NowMs; + } } - /// Force-hides whatever tooltip is currently showing, if any. - /// Session-reset callers use this (mirrors 's - /// own role for dialogs) so a stale popup cannot survive a reconnect. - public void HideCurrent() => RemovePopup(); + /// Force-hides whatever tooltip is currently showing, if any, + /// and forgets the staged world-hover text/guid. Session-reset callers + /// use this (mirrors 's own role + /// for dialogs) so neither a stale popup NOR a stale staged name (which + /// the dwell would otherwise remount over the new session's world with + /// an unmoved mouse) can survive a reconnect. + public void HideCurrent() + { + RemovePopup(); + _worldHoverGuid = 0u; + _worldStagedText = null; + _worldRearmRequiresMouseMove = false; + } /// Retail UIElementManager::StartTooltip @0x0045DE90's text /// + auto-resize step. Wraps at the display width (retail's diff --git a/src/AcDream.App/UI/UiRoot.cs b/src/AcDream.App/UI/UiRoot.cs index 21b61bc1..f22005eb 100644 --- a/src/AcDream.App/UI/UiRoot.cs +++ b/src/AcDream.App/UI/UiRoot.cs @@ -377,6 +377,30 @@ public sealed class UiRoot : UiElement private long _nowMs; + /// Retail UIElementManager::m_lastMouseMoveTime, ported + /// 1:1: stamped UNCONDITIONALLY at the top of every mouse move + /// (MouseMoveHandler @0x0045E710, @0x0045e729/@0x0045e736 + /// — before hit-testing, capture handling, everything) and re-stamped on + /// capture release (ReleaseMouseCapture @0x0045D2B0, + /// @0x0045d2da). Distinct from , whose + /// stamps are deliberately conditional (the !_tooltipFired guard in + /// , no stamp during captured moves) because that + /// field also carries m_bHoverStarted interplay. The world-hover + /// tooltip's idle-dwell gate () + /// needs retail's raw, unconditional timestamp. + private long _lastMouseMoveMs; + + /// Milliseconds since the last mouse move — retail + /// CheckTooltip @0x0045B6E0's dwell operand + /// (@0x0045b747: m_lastMouseMoveTime + delay vs now). + public long MouseIdleMs => _nowMs - _lastMouseMoveMs; + + /// The clock last ran at — retail + /// Timer::local_time as the UI tree sees it. Exposed for sibling + /// per-frame consumers ('s + /// world-tooltip duration clock) so they share ONE frame timestamp. + public long NowMs => _nowMs; + /// Raised when an event was not consumed by any widget. public event Action? WorldMouseFallThrough; @@ -602,6 +626,9 @@ public sealed class UiRoot : UiElement int dy = y - MouseY; MouseX = x; MouseY = y; + // MouseMoveHandler @0x0045e729/@0x0045e736: m_lastMouseMoveTime is + // stamped before ANY routing below (resize/window-drag/capture/hover). + _lastMouseMoveMs = _nowMs; // Window resize takes precedence over move / drag-drop / hover. if (_resizeTarget is not null) @@ -1124,6 +1151,7 @@ public sealed class UiRoot : UiElement // tooltip is already up must leave it up, not clear-then-re-fire it // 250ms later without ever going through TooltipHide. _hoverStartedMs = _nowMs; + _lastMouseMoveMs = _nowMs; // ReleaseMouseCapture @0x0045d2da — the same restart NotifyCaptureLost(previous); if (previous is not null) PointerCaptureChanged?.Invoke(previous, null); @@ -1299,6 +1327,7 @@ public sealed class UiRoot : UiElement public void ResetTooltipTracking() { _hoverStartedMs = _nowMs; + _lastMouseMoveMs = _nowMs; // same fresh idle deadline for the world-hover dwell _tooltipFired = false; } diff --git a/tests/AcDream.App.Tests/UI/Layout/RetailTooltipPresenterTests.cs b/tests/AcDream.App.Tests/UI/Layout/RetailTooltipPresenterTests.cs index 4cdc83a0..12ac3c0d 100644 --- a/tests/AcDream.App.Tests/UI/Layout/RetailTooltipPresenterTests.cs +++ b/tests/AcDream.App.Tests/UI/Layout/RetailTooltipPresenterTests.cs @@ -592,41 +592,103 @@ public sealed class RetailTooltipPresenterTests // ── World-object hover tooltip (docs/ISSUES.md #409 follow-on) ───────── // Port of UIElement_SmartBoxWrapper::RecvNotice_SmartBoxObjectFound - // @0x004E5AD0: edge-fired (no dwell wait), gated by PlayerModule:: - // ShowTooltips, uses the fixed popup-skin pair every game-code - // SetTooltip caller in this family shares (see RetailTooltipPresenter's - // own doc note on why UIElement_SmartBoxWrapper's own P0x47/P0x48 - // cannot be read from the installed DAT). + // @0x004E5AD0's tooltip half, CORRECTED at the 2026-08-17 morning gate + // round (user finding 1: retail world tooltips "lag"; ours popped + // instantly). The notice STAGES the name (SetTooltip @0x004E5D74) and + // the DISPLAY rides UIElementManager::CheckTooltip @0x0045B6E0's + // mouse-idle dwell (m_lastMouseMoveTime + m_tooltipDelay, 250 ms + // default); the notice's own immediate StartTooltipAtMouse @0x004E5DFB + // fires ONLY inside the `m_dragElement != 0` branch (@0x004E5D8E — + // drag-and-drop in progress). Gated by PlayerModule::ShowTooltips at + // the edge; uses the fixed popup-skin pair every game-code SetTooltip + // caller in this family shares (see RetailTooltipPresenter's own doc + // note on why UIElement_SmartBoxWrapper's own P0x47/P0x48 cannot be + // read from the installed DAT). private const uint WorldFoundGuid = 0x80000123u; - [Fact] - public void WorldHover_ShowsImmediately_NoDwellWait() + /// A hit-testable drag SOURCE — presses on it become drag-drop + /// candidates and a captured move past the threshold starts the drag + /// (for the m_dragElement != 0 immediate-mount branch). + private sealed class DragSourceTarget : UiElement + { + public override bool IsDragSource => true; + public override object? GetDragPayload() => "payload"; + } + + private static (UiRoot Root, RetailTooltipPresenter Presenter, List<(uint, uint)> Requests) + CreateWorldHarness(Func guidProvider, Func? nameResolver = null, + Func? enabled = null) { var (root, presenter, requests) = CreateHarness(); - presenter.WorldHoverGuidProvider = () => WorldFoundGuid; - presenter.WorldHoverNameResolver = guid => guid == WorldFoundGuid ? "A Drudge" : null; - presenter.WorldTooltipsEnabled = () => true; + presenter.WorldHoverGuidProvider = guidProvider; + presenter.WorldHoverNameResolver = nameResolver ?? (_ => "A Drudge"); + presenter.WorldTooltipsEnabled = enabled ?? (() => true); + return (root, presenter, requests); + } + + [Fact] + public void WorldHover_StagesOnTheFoundEdge_MountsOnlyAfterTheIdleDwell() + { + // THE morning-gate finding-1 pin: a found-object change stages the + // name but mounts NOTHING until the mouse has been idle for the + // dwell delay (CheckTooltip @0x0045b747's m_lastMouseMoveTime + + // m_tooltipDelay test) — the night round's "edge-fired, no dwell" + // reading mounted immediately, which retail only does mid-drag. + var (root, presenter, requests) = CreateWorldHarness(() => WorldFoundGuid); int childrenBefore = root.Children.Count; - // A single Tick — no root.Tick dwell timer involved at all, unlike - // every UI-element case above. - presenter.Tick(); + root.Tick(0.016, 0); + presenter.Tick(); // the found edge fires here — staged, not shown + Assert.Empty(requests); + Assert.Equal(childrenBefore, root.Children.Count); - Assert.Equal(childrenBefore + 1, root.Children.Count); + root.Tick(0.016, root.TooltipDelayMs - 1); + presenter.Tick(); + Assert.Empty(requests); // one ms short of the idle deadline + + root.Tick(0.016, root.TooltipDelayMs); + presenter.Tick(); Assert.Single(requests, r => r == (0x21000041u, 0x10000395u)); + Assert.Equal(childrenBefore + 1, root.Children.Count); + } + + [Fact] + public void WorldHover_MouseMovingContinuously_NeverMountsUntilItRests() + { + // The user-visible half of finding 1: sweeping the cursor across + // NPCs shows NO tooltips in retail — every move restamps + // m_lastMouseMoveTime (MouseMoveHandler @0x0045e736) so the dwell + // deadline never arrives; the popup appears only once the mouse + // RESTS for the delay. + var (root, presenter, requests) = CreateWorldHarness(() => WorldFoundGuid); + + for (long t = 0; t <= 2000; t += 100) // 100 ms between moves < 250 ms dwell + { + root.Tick(0.016, t); + root.OnMouseMove(100 + (int)(t / 10), 100); + presenter.Tick(); + } + Assert.Empty(requests); + + // Rest: no further moves; the dwell elapses from the LAST move. + root.Tick(0.016, 2000 + root.TooltipDelayMs); + presenter.Tick(); + Assert.Single(requests); } [Fact] public void WorldHover_HidesWhenTheFoundGuidClears() { - var (root, presenter, _) = CreateHarness(); + // found -> 0 stages EMPTY text (ClearTooltip @0x004E5E30 = + // SetTooltip(empty)) whose text-change teardown (@0x004617FF) + // removes the showing popup IMMEDIATELY — the teardown edge is not + // dwell-delayed, only the mount is. uint? found = WorldFoundGuid; - presenter.WorldHoverGuidProvider = () => found; - presenter.WorldHoverNameResolver = _ => "A Drudge"; - presenter.WorldTooltipsEnabled = () => true; + var (root, presenter, _) = CreateWorldHarness(() => found); int childrenBefore = root.Children.Count; + root.Tick(0.016, root.TooltipDelayMs); presenter.Tick(); Assert.Equal(childrenBefore + 1, root.Children.Count); @@ -639,15 +701,15 @@ public sealed class RetailTooltipPresenterTests [Fact] public void WorldHover_ShowTooltipsOff_ShowsNothing() { - // PlayerModule::ShowTooltips @0x004E5D21 gates the whole block — - // UpdateCursorState (the found-cursor swap) is NOT gated by it, but - // that is a separate mechanism this presenter does not own. - var (root, presenter, requests) = CreateHarness(); - presenter.WorldHoverGuidProvider = () => WorldFoundGuid; - presenter.WorldHoverNameResolver = _ => "A Drudge"; - presenter.WorldTooltipsEnabled = () => false; + // PlayerModule::ShowTooltips @0x004E5D21 gates the whole staging + // block — UpdateCursorState (the found-cursor swap) is NOT gated by + // it, but that is a separate mechanism this presenter does not own. + var (root, presenter, requests) = CreateWorldHarness( + () => WorldFoundGuid, enabled: () => false); int childrenBefore = root.Children.Count; + root.Tick(0.016, root.TooltipDelayMs + 50); + presenter.Tick(); presenter.Tick(); Assert.Empty(requests); @@ -657,11 +719,13 @@ public sealed class RetailTooltipPresenterTests [Fact] public void WorldHover_NoNameResolved_ShowsNothing() { - var (_, presenter, requests) = CreateHarness(); - presenter.WorldHoverGuidProvider = () => WorldFoundGuid; - presenter.WorldHoverNameResolver = _ => null; - presenter.WorldTooltipsEnabled = () => true; + // @0x004E5D48: an empty resolved name skips SetTooltip entirely — + // with nothing previously staged, nothing ever mounts. + var (root, presenter, requests) = CreateWorldHarness( + () => WorldFoundGuid, nameResolver: _ => null); + root.Tick(0.016, root.TooltipDelayMs + 50); + presenter.Tick(); presenter.Tick(); Assert.Empty(requests); @@ -675,47 +739,43 @@ public sealed class RetailTooltipPresenterTests // either way the found-object pipeline here must not also fire for // whatever the mouse is currently over. This port narrows that to // "no UI element hovered at all" (see the class's own doc note). - var (root, presenter, requests) = CreateHarness(); + var (root, presenter, requests) = CreateWorldHarness(() => WorldFoundGuid); var uiElement = new HoverTarget { Left = 100, Top = 100, Width = 40, Height = 20 }; root.AddChild(uiElement); root.OnMouseMove(110, 110); - presenter.WorldHoverGuidProvider = () => WorldFoundGuid; - presenter.WorldHoverNameResolver = _ => "A Drudge"; - presenter.WorldTooltipsEnabled = () => true; - + root.Tick(0.016, root.TooltipDelayMs + 50); presenter.Tick(); Assert.Empty(requests); } [Fact] - public void WorldHover_FoundObjectChangesDirectly_ReplacesThePopupWithoutStacking() + public void WorldHover_IdleFoundSwap_ReplacesThePopupTheSameFrame_WithoutStacking() { - // #409 follow-on (2026-08-16 overnight hover/UI round, Batch A bug 1): - // the regression that filled the user's screen with dozens of - // stacked tooltips. Walking past a run of NPCs/doors/lifestones never - // produces a frame where the found guid is 0 — it goes straight from - // A to B to C. RecvNotice_SmartBoxObjectFound-equivalent must still - // only ever have ONE popup mounted: found A, then found B (no - // intervening "nothing found" tick) must swap the popup, not add a - // second one on top of the first. + // Two mechanisms in one scenario. (1) Timing: with the mouse IDLE + // and a popup up, a found A -> B change swaps the popup the SAME + // frame — SetTooltip's text-change teardown (@0x004617FF + // ResetTooltip) tail-calls CheckTooltip, whose dwell deadline + // passed long ago, so the replacement mounts with no new wait. + // (2) The single-slot invariant (#409 follow-on, 2026-08-16 + // overnight round Batch A bug 1): walking past a run of NPCs/ + // doors/lifestones never produces a "nothing found" frame — A->B->C + // must swap ONE mounted popup, never orphan-stack the old ones. const uint otherGuid = 0x80000456u; - var (root, presenter, requests) = CreateHarness(); uint current = WorldFoundGuid; - presenter.WorldHoverGuidProvider = () => current; - presenter.WorldHoverNameResolver = guid => - guid == WorldFoundGuid ? "A Drudge" : "A Door"; - presenter.WorldTooltipsEnabled = () => true; + var (root, presenter, requests) = CreateWorldHarness( + () => current, + nameResolver: guid => guid == WorldFoundGuid ? "A Drudge" : "A Door"); int childrenBefore = root.Children.Count; + root.Tick(0.016, root.TooltipDelayMs); presenter.Tick(); Assert.Equal(childrenBefore + 1, root.Children.Count); current = otherGuid; - presenter.Tick(); + presenter.Tick(); // same frame: teardown + idle remount - // Exactly one popup, not two stacked. Assert.Equal(childrenBefore + 1, root.Children.Count); Assert.Equal(2, requests.Count); @@ -731,6 +791,89 @@ public sealed class RetailTooltipPresenterTests Assert.Equal(childrenBefore + 1, root.Children.Count); } + [Fact] + public void WorldHover_AutoHidesAfterTheDuration_AndRemountsOnlyAfterAMouseMovePlusDwell() + { + // CheckTooltip's duration expiry (@0x0045b78a, m_tooltipDuration = + // 10 s @0x0045f767) tears the popup down AND runs + // SwitchMouseOver(null) (@0x0045b7b2) — m_pElementLastEntered goes + // null, so the dwell CANNOT re-arm until the next real mouse move + // re-enters the wrapper. Without that latch the port would remount + // one frame later (text still staged, mouse still idle) in a 10 s + // flicker loop. + var (root, presenter, requests) = CreateWorldHarness(() => WorldFoundGuid); + int childrenBefore = root.Children.Count; + + root.Tick(0.016, root.TooltipDelayMs); + presenter.Tick(); + Assert.Equal(childrenBefore + 1, root.Children.Count); + + long expiry = root.TooltipDelayMs + root.TooltipDurationMs; + root.Tick(0.016, expiry); + presenter.Tick(); + Assert.Equal(childrenBefore, root.Children.Count); // auto-hidden + + root.Tick(0.016, expiry + 500); + presenter.Tick(); + Assert.Equal(childrenBefore, root.Children.Count); // idle but latched — no flicker remount + Assert.Single(requests); + + long moveAt = expiry + 600; + root.Tick(0.016, moveAt); + root.OnMouseMove(5, 5); // re-enter; dwell restarts from this move + presenter.Tick(); + Assert.Single(requests); // dwell not yet elapsed + + root.Tick(0.016, moveAt + root.TooltipDelayMs); + presenter.Tick(); + Assert.Equal(2, requests.Count); + Assert.Equal(childrenBefore + 1, root.Children.Count); + } + + [Fact] + public void WorldHover_DragInProgress_MountsImmediatelyOnTheFoundEdge_NoDwell() + { + // The ONE immediate path in RecvNotice_SmartBoxObjectFound: + // @0x004E5D8E gates ResetTooltip + StartTooltipAtMouse + // (@0x004E5DF0/@0x004E5DFB) on UIElementManager's m_dragElement — + // while dragging an item over the world, the drop target's name + // shows at once, dwell or no dwell. + uint? found = null; + var (root, presenter, requests) = CreateWorldHarness(() => found); + var source = new DragSourceTarget { Left = 100, Top = 100, Width = 40, Height = 20 }; + root.AddChild(source); + int childrenBefore = root.Children.Count; + + root.Tick(0.016, 0); + root.OnMouseDown(UiMouseButton.Left, 110, 110); + root.OnMouseMove(130, 130); // beyond the 3px threshold -> BeginDrag + Assert.NotNull(root.DragSource); + root.OnMouseMove(300, 300); // over the world, mid-drag, mouse JUST moved + + found = WorldFoundGuid; + presenter.Tick(); // the found edge, zero idle time + + Assert.Single(requests); + Assert.Equal(childrenBefore + 1, root.Children.Count); + } + + [Fact] + public void WorldHover_GlobalEnableOff_SuppressesTheDwellMount() + { + // The dwell-mounted path goes through UIElement::MouseHover, whose + // m_tooltipEnable gate (@0x0046254C) this presenter models as + // Enabled — unlike the drag-immediate branch, which calls + // StartTooltipAtMouse directly and bypasses MouseHover entirely. + var (root, presenter, requests) = CreateWorldHarness(() => WorldFoundGuid); + presenter.Enabled = false; + + root.Tick(0.016, root.TooltipDelayMs + 50); + presenter.Tick(); + presenter.Tick(); + + Assert.Empty(requests); + } + [Fact] public void WorldHover_ThenUiDwellTooltip_ReplacesRatherThanStacks() { @@ -738,19 +881,18 @@ public sealed class RetailTooltipPresenterTests // showing, then the mouse settles on a real UI element (dwell path) // — OnTooltipShow's own unconditional RemovePopup() must clear the // world popup, leaving exactly one popup (the UI one), not two. - var (root, presenter, _) = CreateHarness(); - presenter.WorldHoverGuidProvider = () => WorldFoundGuid; - presenter.WorldHoverNameResolver = _ => "A Drudge"; - presenter.WorldTooltipsEnabled = () => true; + var (root, presenter, _) = CreateWorldHarness(() => WorldFoundGuid); int childrenBefore = root.Children.Count; + root.Tick(0.016, root.TooltipDelayMs); presenter.Tick(); Assert.Equal(childrenBefore + 1, root.Children.Count); // world tooltip up var target = AddFullyAuthoredTarget(root); + long moveAt = root.TooltipDelayMs + 10; + root.Tick(0.016, moveAt); root.OnMouseMove(110, 110); - root.Tick(0.016, 0); - root.Tick(0.016, root.TooltipDelayMs); + root.Tick(0.016, moveAt + root.TooltipDelayMs); UiElement popup = root.Children.Single(c => !ReferenceEquals(c, target)); Assert.NotNull(popup); @@ -786,6 +928,10 @@ public sealed class RetailTooltipPresenterTests // _worldTooltipShowing, which is FALSE here (the currently-mounted // popup is UI-owned, not world-owned) — pre-fix, this let the world // path mount a SECOND popup on top without ever clearing the first. + // Post-finding-1: the mouse has been idle since the UI dwell fired, + // so the world dwell deadline is ALSO already met and the world + // popup mounts on this same Tick (through TryBuildAndMountPopup's + // unconditional clear). var (root, presenter, _) = CreateHarness(); var target = AddFullyAuthoredTarget(root); int childrenBefore = root.Children.Count; @@ -817,13 +963,15 @@ public sealed class RetailTooltipPresenterTests // RecvNotice_SmartBoxObjectFound only re-runs when SmartBox:: // set_found_object's target actually changes — a per-frame poll of // the SAME found id must not re-read ShowTooltips or re-resolve the - // name every tick. - var (_, presenter, requests) = CreateHarness(); + // name every tick, and the dwell mount must not rebuild the popup + // on later ticks either. int gateReads = 0, nameReads = 0; - presenter.WorldHoverGuidProvider = () => WorldFoundGuid; - presenter.WorldHoverNameResolver = _ => { nameReads++; return "A Drudge"; }; - presenter.WorldTooltipsEnabled = () => { gateReads++; return true; }; + var (root, presenter, requests) = CreateWorldHarness( + () => WorldFoundGuid, + nameResolver: _ => { nameReads++; return "A Drudge"; }, + enabled: () => { gateReads++; return true; }); + root.Tick(0.016, root.TooltipDelayMs); presenter.Tick(); presenter.Tick(); presenter.Tick(); @@ -844,11 +992,10 @@ public sealed class RetailTooltipPresenterTests // resolver is free to return whatever plain text it wants and the // presenter applies it verbatim (no separate count formatting is // ever added by this class). - var (root, presenter, _) = CreateHarness(); - presenter.WorldHoverGuidProvider = () => WorldFoundGuid; - presenter.WorldHoverNameResolver = _ => "Iron Bars"; - presenter.WorldTooltipsEnabled = () => true; + var (root, presenter, _) = CreateWorldHarness( + () => WorldFoundGuid, nameResolver: _ => "Iron Bars"); + root.Tick(0.016, root.TooltipDelayMs); presenter.Tick(); UiElement popup = Assert.Single(root.Children);