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

docs(fa5): register rows AD-84/AD-85/AD-86 + AD-82 addendum, gate-script SFA5, ledger

Browse source 
Register:
- AD-84 -- Swear button's missing "target is a player" enable-rule gate,
  same class as AD-83's Recruit-button gap.
- AD-85 -- the unported StringInfo variable-substitution engine (AD-81's
  same root cause) extended to the Allegiance page's numeric-only
  followers/rank/experience-passed-up fields and its three local
  confirmation dialogs (verbatim-or-bare-name, never invented).
- AD-86 -- ACE's deliberate zeroing of seven AllegianceProfile/
  AllegianceData fields (officers, officer titles, MOTD, MOTD-set-by,
  name-last-set-time, lock, approved vassal, timeOnline, allegianceAge),
  dropped past acdream's own parse layer to match retail's own
  gmAllegianceUI, which has no widget for any of them either.
- AD-82 addendum: the vassal-row click-target-only selection shares
  point (3)'s limitation, but NOT the invented leader/selection tints
  (point 1/2) or the Fellowship-only world-selection sync (point 4) --
  Allegiance's list-selection message has no SetSelectedObject call.

Gate script: new docs/research/2026-08-12-campaign-fa-test-script.md
SFA5 section, mirroring SFA4's structure -- the CF-1 subscription steps
(including the reconnect-while-closed MF-3-REOPEN analogue), the SF-7
per-relationship monarch/patron steps, vassal-list steps, swear/break/
kick with their confirmations, the ACE-zeroed-field honesty note, and
full "what to report"/"explicitly not in scope" lists.

Plan ledger: FA5 row filled in against 7ed79eaf with per-item summary,
directly-measured totals (13,296/4/0, +11 net from FA4's 13,285/4/0),
and the two primary-source resolutions this slice needed beyond the
research docs (the self-rank field's live buffed-quality source, and
"your follower count" == _total_vassals, confirmed by a fresh targeted
decompile of UpdatePlayerData rather than inferred).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-12 08:41:10 +02:00
parent 7ed79eaf10
commit bc29a1dbdb
3 changed files with 253 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1,6 +1,6 @@
# Campaign FA connected-gate test script
**Status: FA3 owes its connected gate; FA4 (below) owes its own.** Launch
**Status: FA3, FA4, and FA5 (below) all owe their connected gates.** 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
@ -513,3 +513,240 @@ not a client bug, and is out of scope for this gate either way.]**
plain numeric composites and the raw typed name instead (register row
AD-81); do not report "the text doesn't read like a full sentence" or
"my typed name wasn't auto-capitalized" as bugs.
---
## FA5 — the Allegiance page fully live
**Prerequisite:** open the Allegiance tab (F3, or click it — it is the
authored DEFAULT tab, so simply pressing F3 from a cold start lands here).
All step numbers below restart at 1 for this section's own numbering.
**Honest limitation up front, same shape as FA4's:** swearing allegiance
genuinely needs a SECOND character (you cannot swear to yourself, and
retail requires the target to already be online and selected in the
world). If a second ACE account/character is not available, run every
step marked **[SOLO]** and defer the steps marked **[TWO-CLIENT]** to
Campaign FA slice FA6's bot-vs-ACE gate
(`docs/plans/2026-08-11-fellowship-allegiance-campaign.md`, D8) — do not
treat an unrun two-client step as a failure.
### The data subscription (CF-1) — profile populates on SHOW, not on
`@allegiance info` — [SOLO]
**[FA2 re-review CF-1 correction, carried into this slice's own contract:
the panel's data comes from `0x001F AllegianceUpdateRequest` → `0x0020
AllegianceUpdate`, NOT from the `0x027B`/`0x027C` `@allegiance info`
chat-command pair, which is text-only and does not feed the panel (FA2
MF-2's fix). Do not use `@allegiance info` as a trigger for anything in
this section.]**
1. **With NO allegiance (a fresh character), open the Allegiance tab.**
The self line (your name/rank/follower count) renders at the top;
both the monarch and patron blocks are HIDDEN (no allegiance means
neither relationship exists) — the empty state FA3 already gated, now
reachable live.
2. **If you already have an allegiance (monarch and/or patron), the
blocks should populate WITHIN A SECOND OR TWO of opening the tab** —
this is the `0x001F(1)` → `0x0020` round trip. If the blocks stay
empty indefinitely after opening the tab, that is the CF-1 subscribe
failing to reach the server — a real bug, not a display gap.
3. **Close the panel (or switch to Fellowship), then reopen the
Allegiance tab.** The data should still be there (or repopulate
quickly) — closing/reopening exercises the visible-branch toggle
(`0x001F(0)` on hide, `0x001F(1)` on show) without losing the profile.
4. **[reconnect, the FA4 MF-3-REOPEN analogue] Force a disconnect/
reconnect while ANY allegiance data was previously visible.** Once
the client re-enters the world on the new session, open (or confirm
already-open) the Allegiance tab. EXPECTED: the profile repopulates
on the new session within a second or two — this is
`RedeclareAfterWorldEntry`'s UNCONDITIONAL post-world `0x001F(1)`
resend, which fires regardless of whether the panel happens to be
open at that exact moment (retail's own `RecvNotice_PlayerDescReceived`
arm does not check panel visibility either — see the class doc's CF-1
section). BUG if the profile stays empty/stale for the rest of the new
session — that would mean the exact bug class MF-3-REOPEN caught for
Fellowship's `0x00A6` recurred here for `0x001F`.
### Monarch / patron / self blocks — [SOLO if you already have an
allegiance, otherwise needs a TWO-CLIENT swear first]
5. **Your own line (top of the page) always shows your allegiance's
name, your follower count, and your rank as plain numbers** — retail's
exact sentence wording is NOT reproduced (the unported `StringInfo`
substitution engine, register row AD-85, same class as FA4's AD-81);
do not report "it just shows a number, not a sentence" as a bug.
6. **If you are a VASSAL (you have a patron who is not the monarch)**,
the patron block shows their name and a follower-adjacent
"experience passed up" number. If your patron IS the monarch
(single-tier allegiance), the patron block should be HIDDEN and the
monarch block should show an ADDITIONAL sub-line (the
"experience passed up" number) that does not appear for a
multi-tier allegiance — this is retail's `PatronSlashMonarchLabel`
swap (fix-round SF-7, the coarser FA3 gate's own owed correction).
7. **If you ARE the monarch of your allegiance**, the monarch block
should be HIDDEN (retail hides it when the monarch IS the viewer,
not just when there is no monarch at all) — confirm this specifically
if you can arrange to be a monarch; it is easy to miss since "no
monarch block" looks identical whether you have no allegiance at all
or you're sitting at the top of one.
8. **A logged-out monarch or patron's block should render visually
dimmed** (their name still shows, but the block itself looks
"greyed"/disabled) — retail's `SetState(1)`/`SetState(0xD)` per-block
online/offline toggle. This needs a second client to log out while
you're watching, so mark it **[TWO-CLIENT]** if you can't arrange it
solo.
### Vassal list — [TWO-CLIENT for a populated list; SOLO to confirm the
empty case]
9. **With no vassals, the vassal list box is simply empty** (no
placeholder text, matching retail — there is no "you have no vassals"
frame the way Fellowship has an empty-state frame swap).
10. **With one or more vassals (needs a second character sworn to you —
see the swear steps below), each row shows the vassal's name and an
"experience passed up" number** (their OWN tithed amount, not
yours — distinct from the monarch/patron block's number, which is
YOUR OWN tithed amount).
11. **An OFFLINE vassal's row should visually distinguish itself**
(acdream tints the name grey rather than porting retail's dedicated
offline-marker element visually — confirm SOME visible difference
between an online and offline vassal row).
12. **With several vassals, scroll the list if it overflows the visible
area** and confirm every row remains reachable via the scrollbar
(same `UiTemplateListBox` mechanism FA3/FA4 already gated).
13. **Sibling order — a SOFT/informational check, not a fail-the-gate
item.** If you can arrange three or more vassals sworn to the same
patron in a KNOWN order, the list should render them in REVERSE
swear order (the last one to swear appears FIRST) — this is retail's
own tree-assembly rule (lane C §4.4 point 3), not a display bug. Hard
to verify without careful setup; report what you observe but do not
treat a mismatch as an automatic fail without double-checking the
actual swear order first.
### Swear — [TWO-CLIENT]
14. **On the SECOND client (the would-be vassal, with NO current
patron), select the FIRST client's character in the world** (click
their 3D model) and click **Swear** on the Allegiance page.
EXPECTED: a confirmation dialog appears on the SECOND client asking
to confirm swearing allegiance — the message is whatever retail's
template resolves to VERBATIM, or the target's bare name if the
template did not resolve (register row AD-85 — do not report "the
dialog doesn't read like a full sentence" as a bug).
15. **Accept the dialog on the second client.** EXPECTED: the FIRST
client (the new patron) receives ITS OWN confirmation dialog asking
to accept the new vassal — this is the SERVER-DRIVEN
`ConfirmationType` 1 round trip (`GameplayConfirmationController`,
generic, no allegiance-specific code), showing ACE's own message
(typically just the vassal's bare name, lane C §6.4 — again, not a
full sentence; not a bug).
16. **Accept the dialog on the first client too.** Both clients' Allegiance
pages should update: the second character now shows a patron block
naming the first character; the first character now shows the second
character as a new row in their vassal list.
17. **Swear button enable rule** — with NO current patron and a player
selected in the world who is not already in your allegiance, Swear
should be ENABLED; with a patron already sworn, or nothing selected,
or yourself selected, it should be DISABLED. **[register row AD-84]**
acdream does not check "is the selection a player" the way retail
does — selecting a non-player object (a monster, an item) may leave
Swear lit when retail would grey it out; the server refuses the send
either way, so this is a cosmetic gap, not a wire-behavior bug — do
not fail the gate over it, but do note it if you observe it.
18. **Reject the swear-target dialog (step 14) instead of accepting.** No
dialog reaches the first client; nothing changes on either side.
19. **Reject the accept-swear dialog (step 15) instead of accepting.** The
second character does NOT become a vassal; both clients' allegiance
state stays as it was before step 14.
### Break and Kick — [TWO-CLIENT] (needs an existing swear relationship
from the steps above, or a pre-existing allegiance)
20. **As the VASSAL, click Break.** A confirmation dialog appears asking
to break allegiance FROM your CURRENT patron (target latched at
click time, matching retail — changing your world selection after
clicking Break should NOT change who you break from, since Break's
target is your patron, not a world selection at all). Accept it:
your patron block clears/hides; the patron's vassal list loses your
row.
21. **As the PATRON, select a vassal row (click their name in the vassal
list — NOT the world) and click Kick.** A confirmation dialog
appears asking to kick that SPECIFIC vassal. Accept it: they are
removed from your vassal list; their own client's patron block
clears/hides.
22. **Kick button enable rule** — with no vassal row selected, Kick
should be DISABLED; select any vassal row and it should ENABLE.
23. **Break button enable rule** — with no patron, Break should be
DISABLED; with any patron, it should be ENABLED.
24. **Reject either dialog** (Break or Kick) instead of accepting — no
change on either client, no crash or stuck dialog state.
### The `IgnoreAllegianceRequests` checkbox — [SOLO]
25. **The checkbox on this page and the SAME-named row on the Options →
Character tab are the SAME value** — toggling one should reflect on
the other (open both surfaces side by side, or toggle-then-reopen to
confirm). This bit is a pure server-side filter with no client-side
consumer in retail either (lane C §1.6) — checking it does not change
any OTHER client-visible behavior; do not report "checking it doesn't
seem to do anything" as a bug, that is correct.
### ACE-zeroed fields — honest, not a bug
26. **You will never see officer names, a message-of-the-day, a lock
indicator, or an "allegiance age" anywhere on this page.** Retail's
OWN `gmAllegianceUI` has no widgets for any of these either (they are
chat-verb-only in the 2013 client — `@allegiance officer`, `@allegiance
motd`, etc., all out of this campaign's scope) — do not report their
absence as a bug. Separately, even the CHAT-VERB versions of these
features (if you try them) will show blank/default values against
the currently-targeted ACE build, because ACE deliberately zeroes
these fields on the wire regardless of the allegiance's real state
(register row AD-86) — that is an ACE-vs-retail divergence, not an
acdream bug either way.
### What to report (FA5-specific — in addition to the FA3/FA4 lists above)
- The Allegiance tab NOT being the panel's default (step 1 of §FA3 already
covers the tab itself; this section is about its DATA) — the profile
never populating after opening the tab (step 2), or staying stale
after a reconnect (step 4).
- The monarch block staying VISIBLE while you are the monarch yourself
(step 7), or the patron block staying visible while your patron is the
monarch (step 6) — both are the exact SF-7 per-relationship gate this
slice fixed; a coarse "both blocks show whenever I have ANY profile"
regression would be the FA3 bug resurfacing.
- The monarch/patron "experience passed up" sub-line failing to appear
under the correct block per step 6's single-tier-vs-multi-tier
distinction.
- A vassal row not appearing at all after a successful swear (step 16),
or an online/offline vassal being visually indistinguishable (step 11).
- Swear/Break/Kick sending the WRONG target guid — e.g. Break targeting
something other than your actual current patron, or Kick targeting a
vassal other than the one you clicked.
- Either confirmation-dialog direction of Swear (steps 14/15) not
appearing, or accepting one but not sending the matching wire command.
- The `IgnoreAllegianceRequests` checkbox NOT staying in sync between
this page and the Options → Character tab (step 25).
- Any crash, hang, or exception in the log during swear/break/kick,
during a reconnect with the Allegiance tab open, or while a
confirmation dialog is open.
### Explicitly NOT in scope for this gate (FA5)
- The bot-vs-ACE two-session swear gate (FA6) — every step marked
**[TWO-CLIENT]** above may be deferred there if a second account is
not available for this connected gate.
- Retail's exact `StringInfo`-templated sentences for followers/rank/
experience-passed-up and the three confirmation dialogs — acdream
renders plain numbers and, for dialogs, either retail's unsubstituted
template text or the bare target name (register row AD-85); do not
report "it just shows a number" or "the dialog doesn't read like a
full sentence" as bugs.
- Officer/MOTD/lock/ban/hometown management — chat-verb-only in retail,
out of this campaign's scope entirely (§4 of the plan), and unreliable
against the currently-targeted ACE build regardless (register row
AD-86).
- Swear's missing "target is a player" enable-rule check (register row
AD-84) — a cosmetic superset-of-retail gap, not a wire-behavior bug.