fix #FA4-D6-D7,SF-8: revert three of FA4's four dimming un-dims (IgnoreFellowshipRequests, FellowshipAutoAcceptRequests, FellowshipShareLoot)
The corrected plan D6 (docs/plans/2026-08-11-fellowship-allegiance-campaign.md) established that retail's client reads neither IgnoreFellowshipRequests nor FellowshipAutoAcceptRequests on the fellowship-invite path -- both are pure server-side filters with no client consumer, exactly like the two allegiance bits they were always meant to parallel. Their claimed consumer (RetailUiRuntime.TryAutoRespondToFellowshipInvite) is deleted in a sibling commit this fix round. Both rows revert from Live to StoreOnly. Mechanism review SF-8 additionally found FellowshipShareLoot's claimed consumer -- "a second live checkbox surface on the fellowship page" -- is not a consumer at all: nothing in acdream reads the stored value back (FormatStatsText uses snapshot.ShareXp only; the 0x00A2 Create builder carries shareXP alone), and the live-DAT dump confirms its checkbox is a child of the NOT-in-fellowship frame -- invisible whenever you actually have a fellowship to loot-share within. A second EDITOR of a value is not a CONSUMER of it under AD-78's own "drives nothing observable client-side" definition. FellowshipShareLoot reverts too. Only FellowshipShareXP survives as genuinely live -- the Create-flow click reads it directly as the sent shareXP wire bit. Net: 35 (pre-FA4) -> FA4 shipped 31 -> fix round reverts three -> 34 of 50 dimmed / 16 live, ONE net un-dim from the pre-FA4 baseline, not four. Updated the class doc's derivation table, the conformance test's ExpectedStoreOnlyIds set, and the 31/19 count assertions to 34/16. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
df00030697
commit
300d8189f6
2 changed files with 82 additions and 31 deletions
|
|
@ -111,7 +111,7 @@ public static class CharacterOptionsPageController
|
|||
/// steps 13-18, written after the code landed):
|
||||
///
|
||||
/// <list type="bullet">
|
||||
/// <item><description><b>NOT dimmed (19 rows, real acdream-side
|
||||
/// <item><description><b>NOT dimmed (16 rows, real acdream-side
|
||||
/// consumer):</b> Group B rows actually bound —
|
||||
/// <c>ViewCombatTarget</c>/<c>AutoTarget</c>/<c>AutoRepeatAttack</c>
|
||||
/// (combat: <c>LiveCombatAttackOperations.cs</c>,
|
||||
|
|
@ -125,14 +125,10 @@ public static class CharacterOptionsPageController
|
|||
/// <c>InteractionRetainedUiComposition.cs:326</c>), all six
|
||||
/// <c>ListenTo*Chat</c> ids (<c>TurbineChatMembershipGate.cs:105-136</c>
|
||||
/// gates every Turbine room join on the matching bit), and — landed at
|
||||
/// Campaign FA slice FA4, D7 — <c>IgnoreFellowshipRequests</c>/
|
||||
/// <c>FellowshipAutoAcceptRequests</c> (consumed by
|
||||
/// <c>RetailUiRuntime.TryAutoRespondToFellowshipInvite</c>'s auto-
|
||||
/// decline/auto-accept, D6) and <c>FellowshipShareXP</c>/
|
||||
/// <c>FellowshipShareLoot</c> (consumed by the fellowship page's own
|
||||
/// Create flow / D5 display / second checkbox surface,
|
||||
/// <c>SocialFellowshipPageController</c>).</description></item>
|
||||
/// <item><description><b>Dimmed (31 rows, store-only):</b> every
|
||||
/// Campaign FA slice FA4, D7, SURVIVING the fix-round correction below
|
||||
/// — <c>FellowshipShareXP</c> (the Create-flow click genuinely reads
|
||||
/// it as the sent <c>shareXP</c> bit, <c>SocialFellowshipPageController.WireButtons</c>).</description></item>
|
||||
/// <item><description><b>Dimmed (34 rows, store-only):</b> every
|
||||
/// remaining Group A row (wire+store only — ACE, not acdream, is the
|
||||
/// consumer) and every remaining Group B row the OP4 gate script's own
|
||||
/// step 16 lists as "no consumer surface" (<c>ShowTooltips</c>,
|
||||
|
|
@ -142,9 +138,53 @@ public static class CharacterOptionsPageController
|
|||
/// <c>FilterLanguage</c>, <c>MainPackPreferred</c>), plus every Group D
|
||||
/// deferral (<c>SalvageMultiple</c>,
|
||||
/// <c>DisableHouseRestrictionEffects</c>,
|
||||
/// <c>HearPkDeathMessages</c>) — <c>FellowshipShareXP</c> left Group D
|
||||
/// at FA4 (above), it stays a bullet-list resident here only for the
|
||||
/// historical count.</description></item>
|
||||
/// <c>HearPkDeathMessages</c>).
|
||||
///
|
||||
/// <para>
|
||||
/// <b>FA4 fix-round correction, 2026-08-12 (D6/D7 plan correction +
|
||||
/// mechanism SF-8).</b> FA4 originally un-dimmed FOUR rows here:
|
||||
/// <c>IgnoreFellowshipRequests</c>/<c>FellowshipAutoAcceptRequests</c>
|
||||
/// (claiming a consumer in a client-side invite auto-respond
|
||||
/// interceptor) and <c>FellowshipShareXP</c>/<c>FellowshipShareLoot</c>
|
||||
/// (claiming the fellowship page's own checkbox surface as a
|
||||
/// consumer). Both claims were wrong, for two SEPARATE reasons:
|
||||
/// </para>
|
||||
/// <list type="number">
|
||||
/// <item><description><b>D6's correction (the plan doc, 2026-08-12):</b>
|
||||
/// retail's client reads NEITHER option bit on the invite/confirmation
|
||||
/// path — <c>Handle_Character__ConfirmationRequest @0x005640A0</c>,
|
||||
/// <c>RecvNotice_FellowshipRequest @0x00490880</c>, and
|
||||
/// <c>MakeFellowRequestDialog @0x00490620</c> (whose ONLY guard is
|
||||
/// <c>m_fellowRequestContext</c>) were read in full; a whole-file sweep
|
||||
/// of both accessors finds zero reads on any confirmation path. ACE
|
||||
/// filters both bits SERVER-SIDE. The client-side interceptor
|
||||
/// (<c>RetailUiRuntime.TryAutoRespondToFellowshipInvite</c>) was
|
||||
/// therefore deleted outright — the fellow-invite dialog always shows,
|
||||
/// exactly like retail. <c>IgnoreFellowshipRequests</c>/
|
||||
/// <c>FellowshipAutoAcceptRequests</c> go back to store-only, exactly
|
||||
/// like the two allegiance bits (<c>IgnoreAllegianceRequests</c>/
|
||||
/// <c>DisplayAllegianceLogonNotifications</c>) they were always meant
|
||||
/// to parallel — both pairs are pure server-side filters with NO client
|
||||
/// consumer.</description></item>
|
||||
/// <item><description><b>Mechanism SF-8 (the review, same date):</b>
|
||||
/// <c>FellowshipShareLoot</c>'s claimed consumer — "a second live
|
||||
/// checkbox surface on the fellowship page" — is not a consumer at
|
||||
/// all: nothing in acdream ever READS the stored value back
|
||||
/// (<c>FormatStatsText</c> uses <c>snapshot.ShareXp</c> only; the
|
||||
/// <c>0x00A2</c> Create builder carries <c>shareXP</c> alone), and the
|
||||
/// live-DAT dump confirms its checkbox (<c>0x10000273</c>) is a child
|
||||
/// of the NOT-in-fellowship frame — invisible whenever you actually
|
||||
/// have a fellowship to loot-share within. A second EDITOR of a stored
|
||||
/// value is not a consumer by AD-78's own definition ("drives nothing
|
||||
/// OBSERVABLE client-side"). Only <c>FellowshipShareXP</c> survives —
|
||||
/// its value is genuinely READ by the Create click.</description></item>
|
||||
/// </list>
|
||||
/// <para>
|
||||
/// Net: 35 (pre-FA4) → FA4 shipped 31 → fix round reverts three of the
|
||||
/// four un-dims (Ignore, AutoAccept, ShareLoot) → <b>34 of 50 dimmed /
|
||||
/// 16 live</b>, ONE net un-dim from pre-FA4 baseline
|
||||
/// (<c>FellowshipShareXP</c> only).
|
||||
/// </para></description></item>
|
||||
/// <item><description><b>Flagged ambiguity, resolved by code evidence
|
||||
/// (see final report, not re-litigated here):</b> the research doc's
|
||||
/// §7.1 lists <c>AcceptLootPermits</c> in BOTH Group A's bullet list AND
|
||||
|
|
@ -156,12 +196,11 @@ public static class CharacterOptionsPageController
|
|||
/// <c>IgnoreFellowshipRequests</c>/<c>FellowshipAutoAcceptRequests</c>
|
||||
/// had a genuine coded mutual-exclusion side effect
|
||||
/// (<c>RuntimeCharacterState.TrySetOption</c>, MF-2) that the research
|
||||
/// doc's Group A classification did not capture, kept dimmed at OP1
|
||||
/// pending "a future un-dim is a one-line judgment call, not a
|
||||
/// re-investigation" — that future consumer landed at Campaign FA slice
|
||||
/// FA4 (see D7's addendum to register row AD-78), so both rows moved to
|
||||
/// the NOT-dimmed bullet above, together with the two
|
||||
/// <c>FellowshipShare*</c> rows FA4 also gave real consumers.</description></item>
|
||||
/// doc's Group A classification did not capture — this remains true and
|
||||
/// harmless (the mutual exclusion is enforced regardless of which
|
||||
/// surface's caption is dimmed), but it is NOT itself a client-visible
|
||||
/// CONSUMER of the option's VALUE, so both rows stay dimmed per the
|
||||
/// fix-round correction above.</description></item>
|
||||
/// </list>
|
||||
/// </summary>
|
||||
private const bool Live = false;
|
||||
|
|
@ -203,11 +242,11 @@ public static class CharacterOptionsPageController
|
|||
new("ID_CharacterOption_Grouping_Section", new RowSpec[]
|
||||
{
|
||||
new(CharacterOptionId.IgnoreAllegianceRequests, "IgnoreAllegianceRequests", StoreOnly), // Group A — stays dimmed, D7/AD-78 addendum
|
||||
new(CharacterOptionId.IgnoreFellowshipRequests, "IgnoreFellowshipRequests", Live), // D7/D6 (Campaign FA slice FA4): consumed by the fellowship-invite auto-decline (RetailUiRuntime.TryAutoRespondToFellowshipInvite)
|
||||
new(CharacterOptionId.IgnoreFellowshipRequests, "IgnoreFellowshipRequests", StoreOnly), // fix-round D6 correction: pure server-side filter, NO client consumer — reverted from FA4's Live (see class doc)
|
||||
new(CharacterOptionId.DisplayAllegianceLogonNotifications, "DisplayAllegianceLogonNotifications", StoreOnly), // Group A — stays dimmed, D7/AD-78 addendum
|
||||
new(CharacterOptionId.FellowshipShareXP, "FellowshipShareXP", Live), // D7 (Campaign FA slice FA4): consumed by the fellowship Create flow (its value IS the sent shareXP bit) and the panel's D5 XP-share display
|
||||
new(CharacterOptionId.FellowshipShareLoot, "FellowshipShareLoot", Live), // D7 (Campaign FA slice FA4): now also a SECOND live checkbox surface on the fellowship page itself (SocialFellowshipPageController)
|
||||
new(CharacterOptionId.FellowshipAutoAcceptRequests, "FellowshipAutoAcceptRequests", Live), // D7/D6 (Campaign FA slice FA4): consumed by the fellowship-invite auto-accept (suppresses the confirmation dialog)
|
||||
new(CharacterOptionId.FellowshipShareXP, "FellowshipShareXP", Live), // D7 (Campaign FA slice FA4): consumed by the fellowship Create flow (its value IS the sent shareXP bit)
|
||||
new(CharacterOptionId.FellowshipShareLoot, "FellowshipShareLoot", StoreOnly), // fix-round mechanism SF-8: no real acdream-side READER of the stored value — reverted from FA4's Live (see class doc)
|
||||
new(CharacterOptionId.FellowshipAutoAcceptRequests, "FellowshipAutoAcceptRequests", StoreOnly), // fix-round D6 correction: pure server-side filter, NO client consumer — reverted from FA4's Live (see class doc)
|
||||
}),
|
||||
new("ID_CharacterOption_OtherPlayers_Section", new RowSpec[]
|
||||
{
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue