erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs(fa3): fix gate script tab order + false-defect route, add scroll/restore-open steps, correct #383 timing, fix bold markers + add U11

Browse source 
Mechanism MUST-FIX 1: the connected-gate script's steps 1/9/10 carried
the REFUTED x-order guess forward — claiming Friends was drawn left-most
and that the authored default (Allegiance) was somehow NOT the left-most
tab. The real authored order (fixture + live-mount probe, corroborated
by each page's own P0x57 action-map id) is Allegiance (x=0, DEFAULT),
Fellowship, Friends, Squelch — the default tab IS the left-most tab.
Fixed steps 1, 9, 10, and the "What to report" bullet that repeated the
wrong claim.

Mechanism MUST-FIX 2: step 14 sent the user to `@allegiance info` as a
trigger that would supposedly reveal the monarch/patron blocks, and told
them to report it if it didn't — the trigger CANNOT fire post-FA2
(0x0020 AllegianceUpdate is the only inbound writer of this panel's
data; 0x027C, the @allegiance info response, stopped seeding it in
4272ad0e) and FA3 sends no 0x001F subscription at all (FA5 scope). The
script primed the user to file a false defect. Rewritten to state the
true FA3 expectation: @allegiance info prints real data to chat, the
panel blocks stay hidden regardless, for the whole gate — report
NEITHER half as a bug; the actual anomaly to watch for is the blocks
becoming visible at all.

Mechanism SHOULD-FIX 4: step 11's Fellowship checkbox count hedge
("three... a fourth may also be present") replaced with the settled
count (four).

Blast NIT 8 / gate note: added two steps the original script never
exercised — a long-roster Friends/Squelch scroll check (exactly where
blast MF-1's scrollbar-wiring fix bites, and a short test roster would
never surface it) and an honest restore-open-across-relaunch
observation step (the social panel follows the SAME restore-open
convention every sibling main panel already has — Options/Spellbook/
Character/Inventory/Vitae — stated up front so it isn't mistaken for a
bug mid-gate).

Blast SHOULD-FIX 6: docs/ISSUES.md #383 said the two drifted fixtures
were committed "days ago" — git says otherwise: ~18h and ~21h before the
FA3 regeneration run, the previous day. Corrected, and added the
mechanism reviewer's no-drift finding for the NEW social-panel fixture
(cross-checked against the live probe on every axis, zero drift) —
narrows the issue to exactly the two pre-existing OP-era fixtures.

Blast SHOULD-FIX 7: the §10 addendum in fa-panel-structure.md had five
`**` bold markers (odd count) — an orphaned trailing marker bled bold
formatting into the following section. Dropped the orphan; the addendum
now bolds only its lead sentence and the inline "Allegiance" callout,
both balanced pairs.

Mechanism SHOULD-FIX 1 (research-doc half): filed unknown U11 in §8 —
what a repeat F3/F4 press does when the panel is open on the OTHER tab
is not established from retail decomp (no OnAction consumer exists for
either action in the binary); acdream's own OpenSpellbook-precedent
choice is not a retail port.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-12 03:44:26 +02:00
parent ae77270939
commit a555390483
3 changed files with 137 additions and 46 deletions
Download patch file Download diff file Expand all files Collapse all files

29
docs/ISSUES.md
View file

@ -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

3
docs/research/2026-08-11-fa-panel-structure.md
View file

@ -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`

151
docs/research/2026-08-12-campaign-fa-test-script.md
View file

@ -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.