diff --git a/docs/ISSUES.md b/docs/ISSUES.md index dd07fb1d..98cdc408 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -32,7 +32,14 @@ machine to dump the NEW social-panel fixture also silently rewrote `keyboard_config_21000009.json` and `options_2100002B.json` with LARGE diffs — the currently-installed DATs under `%USERPROFILE%\Documents\Asheron's Call` no longer match the DAT state -those fixtures were committed from (days ago, same machine). The FA3 +those fixtures were committed from. **[FA3 fix-round correction, blast +SF-6:** the original filing said "days ago, same machine" — git says +otherwise. `keyboard_config_21000009.json` was committed at `b4edee97` +(2026-08-11 09:19) and `options_2100002B.json` at `e71e5a96` (2026-08-11 +06:25); the FA3 regeneration run was 2026-08-12 ~02:58 — **~18h and ~21h +earlier, the previous day**, not multi-day drift. That materially tightens +the investigation window below: a same-day change is far easier to +correlate against tooling activity than a multi-day one.]** The FA3 implementer reverted both to HEAD and committed only the new fixture. Possible cause observed in passing: local `mudsort` tooling artifacts in the Documents DAT folder (a DAT-modifying tool may have touched the @@ -40,13 +47,23 @@ files). **Impact/risk:** the committed fixtures drive the conformance suites; the live client reads the INSTALLED DATs — if they diverge, the fixture-green/live-broken class this project keeps meeting gets a new systemic cause. The env-gated live-mount probes (which read the installed -DATs directly) are the cross-check that still holds. **Investigation +DATs directly) are the cross-check that still holds. **[FA3 fix-round +addendum, mechanism review's no-drift finding:** the NEW social-panel +fixture itself is NOT part of this drift — the mechanism reviewer +cross-checked the committed `social_panel_2100006E_1000018F.json` against +the same live-mount probe's dump on root extent, child count and order, +the full tab table, all four pages' `P0x57` values, and both allegiance +blocks' geometry (including the two differently-sized `0x10000490` +instances). No drift; this fixture is faithful to the installed DAT as +committed. **The issue therefore narrows to exactly the two pre-existing, +OP-era fixtures (`keyboard_config_21000009.json`, `options_2100002B.json`) +— the social-panel fixture is not implicated.**]** **Investigation needed before anyone regenerates fixtures on this machine again:** diff the two fixture regenerations structurally (what changed — geometry? -string ids? media?), determine WHAT modified the installed DATs and when, -and decide the canonical DAT source for fixtures (a pristine copy vs the -live install). Do not regenerate-and-commit existing fixtures until the -drift is understood. +string ids? media?), determine WHAT modified the installed DATs in that +~18-21h same-day window, and decide the canonical DAT source for fixtures +(a pristine copy vs the live install). Do not regenerate-and-commit +existing fixtures until the drift is understood. ## #382 — Floating chat-window tab buttons are invisible until first hovered diff --git a/docs/research/2026-08-11-fa-panel-structure.md b/docs/research/2026-08-11-fa-panel-structure.md index a10c86ed..f18bc1d1 100644 --- a/docs/research/2026-08-11-fa-panel-structure.md +++ b/docs/research/2026-08-11-fa-panel-structure.md @@ -832,6 +832,7 @@ blocks a mount. | **U8** | Three low-stakes semantics: input action `0x27` (clears vassal selection, §6.1); the `RegisterNoticeHandler(0x4DD…)` operands (§7.2); the *effect* of Fellowship's message-3 registration given its empty handler (§7.1) | Would need either a cdb trace or notice-table reversing | Only worth doing if a behaviour gap shows up in a connected gate | | **U9** | **Full element-id collision clearance** across every layout acdream mounts | I could only sweep the 33 committed fixtures (§6.4) | After U3, run both panels' resolved id sets against every currently-mounted layout's id set. Prioritise `0x10000490`, `0x10000492`, `0x100004AA`, and treat `0x10000492`'s **intra-panel** duplication as a hard requirement for scoped lookups | | **U10** | The row-template arrays: what LayoutDesc DID + element id sits at **index 0** of `P0x64` on `0x10000279` (fellows) and `0x10000260` (vassals) | Template arrays are authored on the ListBox (Options doc §1.5) | Falls out of U3's dump — read `P0x64` on both ListBoxes and dump the referenced template elements as their own fixtures | +| **U11** | **[FA3 fix-round addendum, 2026-08-12, mechanism SF-1.]** What a repeat F3/F4 press does when the social panel is already open on the OTHER tab — switch, or close-then-reopen, or something else | No `0x1000000E`/`0x1000000F` `OnAction` consumer exists anywhere in the binary: no `GetAttribute_Enum(this, 0x57, …)` read site, `ClientUISystem::OnAction`'s `m_InputAction > 0x7c` branch handles exactly three unrelated ids, and `gmPanelUI::ListenToGlobalMessage` is COMDAT-folded onto a no-op (`NoticeHandler::RecvNotice_DisplayWeenieError @0x004F5860`) | Exhausted for this campaign (see `SocialPanelController.IsShowingAllegiance`'s own doc). acdream ships its own `OpenSpellbook`-precedent convention (switch, not close) — a cdb trace against a live retail client (Step -1 in CLAUDE.md's workflow) is the only remaining way to settle it, and is not worth the cost unless a connected gate reports a mismatch | --- @@ -913,7 +914,7 @@ button 0x1000053B ("Squelch") -> page 0x1000054A (Squelch) ``` The panel's authored default tab is **Allegiance**, not Friends. See `src/AcDream.App/UI/Layout/SocialPanelController.cs`'s own class doc for -the full citation.]** +the full citation.] Every lane-C allegiance element id is CONFIRMED present under page `0x10000291`: swear `0x10000263` / break `0x10000264` / kick `0x10000265` diff --git a/docs/research/2026-08-12-campaign-fa-test-script.md b/docs/research/2026-08-12-campaign-fa-test-script.md index 4d8c302b..94886e04 100644 --- a/docs/research/2026-08-12-campaign-fa-test-script.md +++ b/docs/research/2026-08-12-campaign-fa-test-script.md @@ -18,11 +18,16 @@ absence here. ### Opening the panel — F3/F4, keyboard only 1. **Press F3.** The social panel opens on its **Allegiance** tab (the - authored default tab — NOT Friends, despite Friends being drawn - left-most on the tab strip in some sort orders; Allegiance is retail's - own authored default entry). No toolbar button opens this panel — - retail authors none (lane A §6.1) — so there is nothing to click for - this step besides the keybind itself. + authored default tab — Allegiance is ALSO the left-most tab drawn on + the tab strip, at x=0; the default tab and the left-most tab are the + SAME tab, verified by re-deriving the authored tab table directly from + the fixture, the live-mount probe, and each page's own `P0x57` + action-map id — see `SocialPanelController`'s class doc for the full + citation. **[FA3 fix-round correction, mechanism MF-1]** an earlier + draft of this script claimed Friends was drawn left-most; that was + wrong). No toolbar button opens this panel — retail authors none + (lane A §6.1) — so there is nothing to click for this step besides the + keybind itself. 2. **Press F3 again** while the panel is open and already on the Allegiance tab. The panel closes — same toggle-closes-on-repeat-press shape as every other `Toggle*Panel` action (e.g. F11/Options, @@ -56,30 +61,34 @@ absence here. ### Tab switching -9. **Click each of the four tabs** (Allegiance, Fellowship, Friends, - Squelch — left-to-right authored order is Friends, Allegiance, - Fellowship, Squelch; only ONE tab is highlighted "open" at a time). - Each switches the visible page; exactly one page is visible at a - time. No crash, no stuck state, switching back and forth repeatedly - is safe. -10. **Note the tab captions read correctly** — "Friends", "Allegiance", - "Fellowship", "Squelch" — not blank. A blank caption on any tab - button would be the #375 missing-string-resolver class of bug; - report it immediately if seen. +9. **Click each of the four tabs** (left-to-right authored order: + **Allegiance, Fellowship, Friends, Squelch** — only ONE tab is + highlighted "open" at a time. **[FA3 fix-round correction, mechanism + MF-1]** an earlier draft of this script had the order as + Friends/Allegiance/Fellowship/Squelch; that was wrong — re-derived + directly from the fixture's authored `0x2E` tab table). Each switches + the visible page; exactly one page is visible at a time. No crash, no + stuck state, switching back and forth repeatedly is safe. +10. **Note the tab captions read correctly, in this left-to-right order** + — "Allegiance", "Fellowship", "Friends", "Squelch" — not blank. A + blank caption on any tab button would be the #375 missing-string- + resolver class of bug; report it immediately if seen. ### Fellowship page — empty state 11. **On a character with NO fellowship** (the default state), open the Fellowship tab. Expect: an editable fellowship-name text field, a - **Create Fellowship** button, and three checkboxes (Ignore - Fellowship Requests / Auto-Accept Requests / Share XP — a fourth, - Share Loot, may also be present). No member list, no + **Create Fellowship** button, and FOUR checkboxes (Ignore Fellowship + Requests / Auto-Accept Requests / Share XP / Share Loot — **[FA3 + fix-round correction, mechanism SF-4]** an earlier draft hedged this + as "three... a fourth may also be present"; the fixture and the + decomp both settle it at four). No member list, no leader/quit/open/recruit/dismiss/disband buttons visible — those belong to the OTHER (in-fellowship) frame, which is hidden. **INERT:** the Create Fellowship button, the name field, and all - visible checkboxes do nothing yet on click/edit (FA4 wires the - create flow and the checkboxes already have Options-tab live - consumers — this page's OWN copies are not yet cross-bound). + four checkboxes do nothing yet on click/edit (FA4 wires the create + flow and the checkboxes already have Options-tab live consumers — + this page's OWN copies are not yet cross-bound). 12. **If the test character IS currently in a fellowship** (uncommon for `+Acdream`'s default state, but possible if a prior session left one active), open the Fellowship tab instead expecting: a fellowship @@ -97,14 +106,26 @@ absence here. the vassal list area remain visible per their authored layout. The Swear/Break/Kick buttons and the "Ignore Allegiance Requests" checkbox are present and **INERT**. -14. **This state may not change automatically** — FA3 does not send the - `0x001F AllegianceUpdateRequest` subscription (that is FA5 scope, per - the plan's corrected D6/CF-1 note), so simply opening the tab will - NOT cause a profile to arrive. If some other client action causes an - allegiance push to land server-side during this session (e.g. a - `@allegiance info` chat command, which already works independently of - this panel), the monarch/patron blocks should then become VISIBLE — - report if they do not. +14. **This state does NOT change for the rest of this gate — that is the + correct, contracted FA3 behavior, not a bug. [FA3 fix-round + correction, mechanism MF-2]** an earlier draft of this script sent + you to `@allegiance info` expecting it to make the blocks visible, + and told you to report it if that didn't happen. That trigger CANNOT + fire and the instruction was wrong: FA3 never sends the `0x001F + AllegianceUpdateRequest` subscription (FA5 scope, per the plan's + corrected D6/CF-1 note), and `0x0020 AllegianceUpdate` — the ONLY + inbound message that can populate this panel's data — is never + provoked by anything FA3 does. Running `@allegiance info` in chat + still works exactly as before FA3 (it is an independent, already- + shipped command) and WILL print your monarch/patron/vassal data as + chat TEXT — but its response (`0x027C`) stopped seeding this panel's + profile back in FA2 (`4272ad0e`), so it has zero effect on this page. + **The correct, expected combination for this entire gate is:** + `@allegiance info` prints real data to the chat window (if you have + an allegiance), AND the Allegiance page's monarch/patron blocks stay + hidden throughout — report NEITHER half as a bug. The panel blocks + becoming visible at any point during this gate (see "What to report" + below) is the actual anomaly to watch for. ### Friends page — read-only list @@ -125,24 +146,70 @@ absence here. 18. **The three action-shaped buttons are INERT** (register row AD-79, same as Friends). CONTRACTED, do not report. +### Scrolling a long roster + +**[FA3 fix-round addition, blast N-8/MF-1]** the two ListBoxes' own +scrollbars were unwired until this fix round — completely unreachable +past the visible extent, not merely awkward to use. This step exercises +the fix directly. + +19. **If the test account's Friends or Squelch roster is longer than + fits in the panel's visible area** (the Friends box is 270×400 but + the panel itself is only ~300×362, so as few as a dozen or so + entries can already overflow — check either tab), **drag the + scrollbar thumb (or click the track/arrows) and confirm the rows + scroll and every name remains reachable**, all the way to the last + row. This is a **soft check** if the test account's roster is + genuinely too short to overflow — do not manufacture a long roster + just to exercise this step, but if the roster IS long enough, a + scrollbar that does not move the list, or a list that will not + scroll at all, IS a bug — report it. + ### Live update while the panel is closed -19. **This is a soft check, not required to pass/fail the gate:** if +20. **This is a soft check, not required to pass/fail the gate:** if Friends/Squelch state changes server-side while the social panel is CLOSED (e.g. via `@friend` chat commands, if any are wired), then reopening the panel afterward should show the up-to-date list - immediately (the read-only binding polls every frame regardless of - which tab or window is visible — see - `SocialFriendsPageController`/`SocialSquelchPageController`'s own - doc comments). Report if the list is stale on reopen. + immediately (the read-only binding polls every frame WHILE THE PANEL + IS VISIBLE — **[FA3 fix-round correction, blast SF-2]** an earlier + draft of this script said the poll runs "regardless of which tab or + window is visible"; that changed in the fix round — the rebuild is + now gated on the social panel's own visibility so it does no DAT + work while closed, but it still catches up in full the moment the + panel is shown again, so the user-visible outcome described here is + unchanged. See `SocialFriendsPageController`/ + `SocialSquelchPageController`'s own doc comments). Report if the + list is stale on reopen. + +### Window restore-open behavior across relaunch + +**[FA3 fix-round addition, blast N-8]** stated honestly rather than left +untested: the social panel is NOT in acdream's short list of windows +whose OPEN/CLOSED state is force-reset every session +(`stateManagedVisibilityWindows` — Combat/JumpPowerbar/ +ExternalContainer/Vendor). This is a deliberate, documented choice +(the FA seams doc), and it matches the EXACT SAME convention every +sibling main panel already uses — Options, Spellbook, Character, +Inventory, and Vitae all restore their own last open/closed state too. + +21. **Open the social panel (F3 or F4), then close the client and + relaunch (or simply log out and back in without closing the + window).** The EXPECTED, non-bug behavior is that the social panel + reopens automatically in whatever tab/open state it was left in — + the SAME restore-open behavior every other main panel already has. + This is not something to report; it is only listed here so the + behavior is understood in advance rather than surprising anyone + mid-gate. --- ### What to report - Any tab caption that renders blank instead of its retail name. -- The panel opening on the wrong DEFAULT tab (should be Allegiance, not - Friends) on a fresh F3 press with the panel previously closed. +- The panel opening on the wrong DEFAULT tab (should be Allegiance, and + Allegiance is also the left-most tab) on a fresh F3 press with the + panel previously closed. - F3/F4 failing to switch tabs while the panel is already open, or closing the panel when it should only switch tabs. - The panel NOT closing/opening exclusively with sibling `gmPanelUI` @@ -150,15 +217,21 @@ absence here. - The Fellowship page showing the WRONG frame for the character's actual fellowship state (e.g. showing the roster/six-button frame while `+Acdream` has no fellowship). -- The Allegiance page's monarch/patron blocks staying hidden after a - real allegiance push has visibly landed (e.g. after `@allegiance info` - shows non-empty data in chat). +- The Allegiance page's monarch/patron blocks becoming VISIBLE at ANY + point during this gate — there is no code path in FA3 that can make + that happen (see step 14); if it happens, that is a real bug (an + accidental wire connection), not the false-defect trigger an earlier + draft of this script pointed at. - Any INERT button/checkbox producing a VISIBLE effect (a Create Fellowship, Swear, Friends, or Squelch action that unexpectedly does something) — this would mean either an accidental wire connection or a stale INERT claim in this script. - A Friends/Squelch row showing anything other than a plain name (an exception, a blank row, garbled text). +- A Friends/Squelch scrollbar that does not move the list, or a + longer-than-visible roster with no way to reach its later rows (step + 19) — only when the test account's roster is actually long enough to + overflow. - Any crash, hang, or exception in the log while opening/closing/ switching tabs repeatedly.