acdream/docs/research/2026-08-12-campaign-fa-test-script.md
Erik a555390483 docs(fa3): fix gate script tab order + false-defect route, add scroll/restore-open steps, correct #383 timing, fix bold markers + add U11
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>
2026-08-12 03:44:26 +02:00

13 KiB
Raw Blame History

Campaign FA connected-gate test script

Status: FA3 owes its connected gate. Launch with ACDREAM_LIVE=1 against the local ACE server (testaccount / +Acdream). Anything marked INERT is authored and clickable but deliberately does nothing yet — that is the correct, contracted behavior for this slice (D1), not a bug.

FA3 is the panel SHELL only: mount, F3/F4 open paths, tab switching, all four pages' empty states, and Friends/Squelch read-only lists. Fellowship roster rows, the create-fellowship dialog, live vitals, and every Allegiance swear/break/kick action are FA4/FA5 scope — do not report their absence here.


FA3 — the social panel shell

Opening the panel — F3/F4, keyboard only

  1. Press F3. The social panel opens on its Allegiance tab (the 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, Spellbook).
  3. Press F4. The social panel opens directly on its Fellowship tab (F4 switches AND opens in one press, even if the panel was closed).
  4. With the panel open on Fellowship, press F3. The panel does NOT close — it switches to the Allegiance tab (F3 is scoped to its own tab, not a blanket close). Symmetrically, pressing F4 while open on Allegiance switches to Fellowship rather than closing.
  5. Click the panel's own close (X) button, top-right of the window chrome. The panel closes — same action as a repeat F3/F4 press on the already-active tab.
  6. Drag the window by its border/chrome; resize it from the BOTTOM edge only. Same shared gmPanelUI geometry policy as every sibling main panel (Options, Character, Inventory, Spellbook, the indicator-detail panels): draggable, resizable from the bottom edge only, remembers its height across a close/reopen within the session.

Exclusivity vs sibling panels

  1. Open Character Info (or Inventory, or Options), then press F3. The other panel closes and the social panel opens on Allegiance — the SAME retail gmPanelUI one-active-panel-at-a-time behavior every sibling panel already has (RetailPanelUiController.RegisterMainPanel shares one geometry rectangle across all ten registered main panels).
  2. With the social panel open, open Character Info. The social panel closes. Confirms the exclusivity is bidirectional, not just "opening the social panel closes others."

Tab switching

  1. 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.
  2. 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

  1. 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 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 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).
  2. 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 name display, a member roster ListBox (empty rows — FA4 populates them), and six buttons (Leader/Quit/Open/Recruit/Dismiss/Disband). All six buttons are INERT for FA3.

Allegiance page — empty state

  1. On a character with NO allegiance profile ever received this session (the default state — nothing has queried allegiance data yet), open the Allegiance tab. Expect: the monarch block and patron block BOTH HIDDEN (no visible "Monarch:" / "Patron:" labels or name lines), while your own character line (name/followers/rank) and 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.
  2. 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

  1. Open the Friends tab. If the test account has any friends server-side, their NAMES appear as rows in the list (no online/ offline styling, no icons — names only, this slice's explicit scope). If the account has none, the list is empty (no placeholder text is invented).
  2. The three action-shaped buttons and the "Appear Offline"-shaped checkbox are INERT — clicking/toggling them does nothing (register row AD-79). This is CONTRACTED for FA3; do not report it.

Squelch page — read-only list

  1. Open the Squelch tab. If the test account has any squelched characters or accounts, their names appear as rows (characters and account-level squelches both listed, names only). Empty otherwise.
  2. 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.

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

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

  1. 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, 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 panels (Character/Inventory/Options/etc.).
  • 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 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.

Explicitly NOT in scope for this gate

  • Fellowship roster population, vitals, the create-fellowship dialog, recruit/dismiss/leader/open/disband wire sends, and the option-row un-dims (FA4).
  • Allegiance monarch/patron/vassal LIVE population, swear/break/kick wire sends, and their confirmation dialogs (FA5).
  • Friends/Squelch add/remove/appear-offline/clear wire sends (D1 — out of campaign scope entirely, register row AD-79).
  • The bot-vs-ACE two-session fellowship gate (FA6).