Opus dual-lens review of CT2 (bcfddc97) found 4 SHOULD-FIX + notes; this
applies the campaign lead's rulings.
F1 (the important one): retail's client-side table add is DEDUPED —
gmCharacterTitleUI::RecvNotice_AddCharacterTitle @0x0049a990 walks
mTitleList and returns without effect when the id is already present,
only inserting on a miss. The server-side SendNotice_AddCharacterTitle
broadcast is unconditional, but RuntimeCharacterTitleState.ApplyUpdateTitle
models the CLIENT receive side, so TitleAdded now fires only on a genuine
new membership. Inverted the pin:
ApplyUpdateTitle_AlreadyEarnedId_DoesNotFireTitleAddedOrBumpRevision.
F3: removed the send-side titleId==0 rejection from both command
adapters. Retail's own send path (Event_SetDisplayCharacterTitle
@0x006a5720) packs whatever id it is handed, and ACE accepts id 0
(CharacterTitle.Invalid is a defined enum value) — retail's real
protection is the UI ghost-when-current gate (CT3's job), not a
send-side rejection. No register row: this makes acdream MORE
retail-exact.
A2: ResetSession now publishes TableReplaced unconditionally and
DisplayTitleChanged when the display id was non-zero before the clear,
matching the LocalPlayerState.Clear() precedent (publish every category
even when Clear is repeated, so a failed reset can converge on retry).
A3: RuntimeCharacterState.CaptureOwnership reads the new non-allocating
Titles.Count instead of EarnedTitleIds.Count; EarnedTitleIds now carries
an XML warning that every read allocates.
A4/A5: ReplaceTable/ApplyUpdateTitle now mutate under one _gate hold with
change flags computed inside the lock and events raised after release;
every revision bump is gated on an actual state change (a no-op wire
resend produces zero revision edges), matching the change-gated
RuntimeMovementSkillState precedent. TableReplaced itself still fires
unconditionally per retail's own Refresh() dispatch on 0x0029.
A1/A6/A7/A8: CharacterTitleResolverLiveDatTests honors ACDREAM_DAT_DIR
first (CT1 fix-round pattern); documented the EmitResult
primaryObjectId-as-title-id precedent inline; corrected the "third
consumer" comment (CT1 §5 already records gmAttributeUI::PostInit's
icon-DID lookup — CT5 factors the shared GetDIDByEnum helper); added a
titleId -> resolved-string memo to CharacterTitleResolver, the DAT-static
equivalent of retail's lazy-hash cache on the string buffer.
Appended a "CT3 anchors from the CT2 review" list to the plan doc's CT2
ledger entry for CT3 to consume.
Build green. Runtime (102), Core.Net (12), and App (27 + 3 InstalledDat
pins under ACDREAM_RUN_INSTALLED_DAT_TESTS=1) title-scoped tests pass.
Full hermetic solution suite (Lane exclusions per the release gate) is
green: 0 failures across all 15 test projects.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Campaign CT slice CT2: the client now learns the character's earned
titles and current display title from the server, owns that state in
Runtime, and can send a display-title change. No UI (CT3/CT4).
Wire (Core.Net):
- GameEvents.ParseCharacterTitleTable (0x0029 CharacterTitle): retail
CharacterTitleTable::UnPack @0x005c6e90 skips a leading u32 into no
field — its own Pack @0x005c6e40 always writes the literal 1 there,
matching ACE's unconditional Writer.Write(1u) — then reads
displayTitleId, then a count-prefixed PList<uint> of earned ids.
- GameEvents.ParseUpdateTitle (0x002B UpdateTitle): titleId +
setAsDisplay, per CM_Social::DispatchUI_AddOrSetCharacterTitle
@0x006a54c0 -> Handle_Social__AddOrSetCharacterTitle @0x00564260,
which ALWAYS adds (SendNotice_AddCharacterTitle, unconditional) and
additionally sets display only when setAsDisplay != 0
(SendNotice_SetDisplayCharacterTitle, gated).
- SocialActions.BuildTitleSet / WorldSession.SendSetTitle: outbound
TitleSet (0x002C), u32 titleId, matching ACE's GameActionSetTitle.
- GameEventWiring gains onCharacterTitleTable/onUpdateTitle delegate
holes (Core.Net cannot reference AcDream.Runtime directly).
Runtime:
- New RuntimeCharacterTitleState (RuntimeCharacterState.Titles): earned
title id set + display title id, TableReplaced/TitleAdded/
DisplayTitleChanged events matching retail's unconditional-add /
gated-display-set contract, clears at generation reset.
RuntimeCharacterOwnershipSnapshot/CaptureOwnership/IsConverged and
RuntimeCharacterSnapshot extended (trailing optional fields, no
existing call site broken).
- IRuntimeCharacterCommands.SetTitle: generation-gated, sends
TitleSet only — NO optimistic local mutation. Verified against
retail's own CM_Social::Event_SetDisplayCharacterTitle @0x006a5720,
which sends the wire message and touches no local field; the display
title updates only from the server's own echo (the CA-campaign
lesson: never re-add an optimistic write). Implemented on both hosts
(DirectGameRuntimeCommandAdapter direct-send;
CurrentGameRuntimeCommandAdapter via LiveCommandBus /
LiveSessionCommandRouter's new SetTitleRuntimeCmd).
- LiveSessionEventRouter wires the two inbound events unconditionally
(RuntimeCharacterState.Titles is a required child, not an optional
sibling like Fellowship/Allegiance).
App (non-UI plumbing + resolver):
- CharacterTitleResolver (src/AcDream.App/UI/Layout/): ports
CharacterTitleTable::GetCharacterTitleFromID @0x005c6ed0 — titleId ->
EnumMapper(0x22000041) canonical key -> compute_str_hash ->
StringTable(0x2300000E) localized text. Runtime stays id-only; CT3/
CT4 consume this for display. DIDs hardcoded per the RetailKeyNames
precedent (CT1 verified them end-to-end).
Register: no new row. Retail's send path is non-optimistic and so is
ours — no deviation to record for this slice.
Tests: wire conformance (byte-exact + truncation) in
CharacterTitleEventsTests.cs + SocialActionsTests.cs; Runtime owner
unit tests in RuntimeCharacterTitleStateTests.cs plus integration in
RuntimeCharacterStateTests.cs; a no-local-mutation command test in
DirectGameRuntimeCommandAdapterTests.cs; an InstalledDat pin
(CharacterTitleResolverLiveDatTests.cs, ids 0/1/2/3/5/13/14, run green
with ACDREAM_RUN_INSTALLED_DAT_TESTS=1). Full solution build green;
hermetic filtered suite green (15,380 passed / 0 failed).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Erik