acdream/docs/research/2026-08-21-retail-chat-window-ui.md

Retail chat WINDOW shell — window model, filters, scrollback, chrome

Date: 2026-08-21 Status: RESEARCH ONLY. No source files touched. Scope: retail's chat window SHELL and DISPLAY behavior — window management, filtering, scrollback, chrome/interaction, multi-window, line-composition structure, and other user-visible window mechanics. Explicitly out of scope (covered by sibling research this session): glyph text-tag coloring, clickable/colored names, tag click dispatch, and acdream's own current UI code. This document does not re-derive anything already answered there.

Primary sources

• docs/research/named-retail/acclient_2013_pseudo_c.txt (Sept 2013 EoR build, Binary Ninja pseudo-C, PDB-named)
• docs/research/named-retail/acclient.h (verbatim retail struct/enum defs)
• docs/research/named-retail/symbols.json

Notes read first so this extends rather than repeats:

• docs/research/2026-08-09-chat-retail-window-shell.md (CH6 shell research — window lifecycle/identity, LayoutDesc geometry, resize model, opacity, persistence, multi-window/floaty mechanics). This document is the authority for §1 window-lifecycle mechanics, §4 chrome/resize/opacity, and §5 tabs/multi-window — I only summarize its findings below with pointers, and add what it doesn't cover: scrollback/truncation, the exact window-ID routing predicate as a single decompiled function, structural line-composition order, and the unseen-text/auto-scroll interaction.
• docs/research/2026-08-09-chat-retail-color-table.md §4 (filter storage, m_llTextTypeFilter, PostInit seeded defaults) — I summarize and do not re-derive; I use its findings to cross-check the routing function decoded fresh below.
• docs/plans/2026-08-09-chat-parity-campaign.md — Campaign CH plan/ledger.

Binary-Ninja caveats (apply throughout, per claude-memory/feedback_bn_decomp_field_names.md): BN's struct-field attribution in ChatInterface::PostInit/gmMainChatUI::PostInit is shifted by one slot relative to the true member order — the window-shell doc already documented this for the main window's border elements. I hit the same artifact in ChatInterface::PostInit's GetChildRecursive binding sequence (§1) and resolve it the same way: against the verbatim struct order in acclient.h:54898-54912, which is authoritative and does not shift.

---

1. Window model

1.1 How many windows, and how they're identified

Confirmed against acclient.h:54898-54912 (verbatim ChatInterface struct):

/* 6041 */
struct __cppobj ChatInterface : gmNoticeHandler, UIElement_Field
{
  unsigned int m_eWindowID;
  float m_fDefaultOpacity;
  float m_fActiveOpacity;
  float m_fCurrentOpacity;
  UIElement_Text *m_chatEntry;
  UIElement_Text *m_chatLog;
  UIElement *m_chatNewNonVisibleTextIndicator;
  unsigned __int64 m_llTextTypeFilter;
  UIElement_Text *m_pChatTargetButtonText;
  PStringBaseArray<unsigned short> m_InputHistory;
  unsigned int m_LastInputHistoryPos;
  ClientCommunicationSystem *m_pCCS;
};

Per the window-shell doc §1.2/§4.1 (not re-derived here): five live chat windows exist — the main window (m_eWindowID == 8) and four floating windows (m_eWindowID == 2..5). m_eWindowID == 0 is the UNAUTHORED constructor default (ChatInterface::ChatInterface @0x004F4550 sets this->m_eWindowID = 0; before PostInit reads the real value off the LayoutDesc attribute 0x1000007E). All five windows are authored, always-resident children of the gameplay-UI root — there is no runtime-allocated window registry (window-shell doc §1.1).

The SpewBox (gmSpewBoxUI) is a separate, unrelated class — not a ChatInterface subclass, not part of this window-id space (per claude-memory/project_chat_digest.md).

1.2 The wire-to-window routing predicate — one function, load-bearing

ChatInterface::RecvNotice_DisplayFinalStringInfo @0x004F4640 is the single function every displayed chat line passes through. Its head (the routing decision, before any text is appended) is:

004f4640  void __thiscall ChatInterface::RecvNotice_DisplayFinalStringInfo(
              class ChatInterface* this, uint32_t arg2 /*type*/,
              class StringInfo const* arg3 /*body*/,
              class StringInfo const* arg4 /*prefix*/, uint32_t arg5 /*windowId*/)
004f4640  {
004f4640      uint32_t eax_7 = arg5;
004f4652      if (eax_7 == this->m_eWindowID)
004f4652      {
004f467c      label_4f467c:
                  … (appends — see §3/§6) …
004f4652      }
004f4652      else if ((eax_7 == 0 && ChatInterface::TypeIsActive(this, arg2) != 0))
004f4666          goto label_4f467c;
004f4640  }

The predicate is exactly: windowId == m_eWindowID OR (windowId == 0 AND TypeIsActive(type)). This is an ADDRESS-vs-BROADCAST model, not a "windows subscribe to a channel" model:

• A line sent with a specific windowId (matching an already-open target window, e.g. a command whose output is explicitly directed at the window that issued it — m_idCurrentCommandSource per the color-table doc §4) is shown only in that one window, unconditionally — the destination window's own filter is never consulted for an address-targeted line.
• A line sent with windowId == 0 ("broadcast") is shown in every window whose own TypeIsActive(type) (i.e. its 64-bit m_llTextTypeFilter, decoded in the color-table doc §4) says yes. This is how the same "Sio says, ..." line can land in the main window and in a floating window simultaneously if both have Speech enabled.
• Window id 0 is therefore never itself a window — it is the broadcast sentinel value on the wire/call parameter, exactly as the window-shell doc's goal-window addendum states. No live ChatInterface instance ever keeps m_eWindowID == 0 after PostInit runs.

ChatInterface::TypeIsActive @0x004F2F10 (cited, not re-derived, per the color-table doc §4) is (1ULL << type) & m_llTextTypeFilter.

---

2. Filters

Fully decoded already in 2026-08-09-chat-retail-color-table.md §4 — not re-derived here. Summary for completeness of this document's structure:

• Storage: 64-bit ChatInterface::m_llTextTypeFilter (acclient.h:54907), read from PlayerModule::InqChatWindowOption(windowId, 0x1000007F, …) (ChatInterface::UpdateFromPlayerModule @0x004F3920) and live-updated via RecvNotice_GameplayOptionChanged @0x004F30E0.
• Test: ChatInterface::TypeIsActive @0x004F2F10 — (1ULL << type) & m_llTextTypeFilter, used both for the broadcast-routing predicate (§1.2) and, per the color-table doc, nowhere else.
• PostInit's per-window seeded default switches on m_oldState (ChatInterface::PostInit @0x004F3DD0, 0x004f3df9): 1 and 8 (the main window) get 0xFBFFFFFF low-dword (everything except client-local 0x1A); 2 (floaty 1) gets Speech/Tell/Speech_Direct_Send/Emote; 3 (floaty 2) gets Social/Social_Send/Allegiance; 4 (floaty 3) gets Fellowship; 5 (floaty 4) gets the four Turbine rooms General/Trade/LFG/Roleplay. Every default's HIGH dword is 0 — Society (0x20) and the reserved 0x21 slot start disabled in every window and must be opted into by the user.
• User edit path: gmChatOptionsUI::InitOptions @0x0049FC60 / AddCheckboxBitfield64Option @0x0049EDA0 build one checkbox-grid SetUserData block per window id (main = id 8, with its own dedicated Society checkbox child at 0x0049FEFB).
• Squelching is a separate axis from filtering: LogTextTypeEnumMapper::IsLegalChannel @0x006AFF40 whitelists a 14-value subset of LogTextType as squelchable at all; it has no interaction with m_llTextTypeFilter.

Nothing new to add here beyond what the color-table doc already covers — the routing predicate decoded fresh in §1.2 above is a second, independent confirmation of the same "windowId==0 → filter-gated broadcast" model that doc's §4 described from RecvNotice_DisplayFinalStringInfo's citation alone; this document supplies the full decompiled function body.

---

3. Scrollback

3.1 The cap, the trigger, and the trim target

Still inside RecvNotice_DisplayFinalStringInfo @0x004F4640, immediately after the body append (full excerpt with the append order in §6):

004f4701          int32_t m_chatLog_1 = this->m_chatLog;
004f4711          if (*(uint32_t*)(m_chatLog_1 + 0x61c) > 0x2710)
004f4711          {
004f4713              int32_t var_14_4 = 0x1d4c;
004f471a              m_chatLog_1 = ChatInterface::TruncateChatLog(this, m_chatLog_1);
004f4711          }

0x2710 = 10,000, 0x1d4c = 7,500. The field read at transcript offset +0x61C tracks the transcript's total character count (not a line count) — retail's scrollback limit is a character budget, not a fixed number of retained lines. Trigger: transcript exceeds 10,000 characters. Target: trim back down toward ~7,500. This runs on every appended line once the log is over budget — it is not a periodic/timed sweep, it is inline in the same call that just displayed the line.

3.2 The truncation rule — trims at a newline boundary, not mid-line

ChatInterface::TruncateChatLog @0x004F4290 (arg2 = target length, 7500 at the only call site found):

004f4290  void __fastcall ChatInterface::TruncateChatLog(class ChatInterface* this, uint32_t arg2)
004f4290  {
              text = GetText(m_chatLog);           // live PStringBase
              currentLen = text.length;             // *(len_ptr - 4)
004f42c2      if (currentLen <= arg2)
                  return;                            // under budget — no-op
004f42c2      else
              {
004f42c8          excess = currentLen - arg2;        // chars over target
                  … PStringBaseIter_Common<unsigned short>::FindChar(iter, "\n", 1) …
                  // search FORWARD from the excess offset for the next '\n'
004f4350          if (found && (excess - foundPos) < (currentLen / 10))
004f4360              BeheadText(m_chatLog, foundPos + 1, 1);   // cut at that newline
                  else {
                      … FindChar(iter, "\n", 0) …               // search again, other direction arg
004f43f0              if (found2 && (foundPos2 - excess) < (currentLen / 10))
                          goto (the same BeheadText-at-newline path)
004f4403              else
                          BeheadText(m_chatLog, excess, 1);     // fallback: cut at the raw excess offset
              }
004f4290  }

Reading this at the BN pseudo-C level is genuinely uncertain past the overall shape — flagging per the assignment's constraint rather than guessing: the 0xCCCCCCCD multiply + HIGHD(...) >> 3 pair is the standard MSVC constant-division-by-10 idiom (length / 10), and the two FindChar calls with a PStringBase(&data_79c288) needle (confirmed below, §3.3, to be a single \n character) plus UIElement_Text::BeheadText are unambiguous. UNKNOWN — needs a live cdb capture with real transcript content to nail down exactly: whether the two FindChar calls search in opposite directions from the excess offset (my reading above) or whether one is a fallback re-search after the first's 10%-tolerance check fails for a different reason; the two arg3 values passed to FindChar (1 then 0) are almost certainly a direction or "case-sensitive/whole-word" flag, but the pseudo-C never names the parameter. What is certain and sufficient to port: truncation removes text from the FRONT of the transcript (BeheadText), it PREFERS a boundary within the char that begins the next \n-terminated line rather than a raw char-offset cut (there's a ~10%-of-current-length tolerance band around the target for preferring the newline-aligned cut), and it falls back to an exact char-offset behead only if no acceptable newline is found nearby.

3.3 The separator character — confirms \n, not \r\n

0079c280  data_79c280:  0d 00 0a 00 00 00 00 00     // L"\r\n" — used elsewhere, NOT here
0079c288  data_79c288:  0a 00 00 00 00 00 00 00     // L"\n"  — the separator + the TruncateChatLog needle

data_79c288 is passed both as the inter-line separator string appended in RecvNotice_DisplayFinalStringInfo (§6) and as the FindChar needle in TruncateChatLog above — confirming truncation genuinely searches for line breaks, i.e. it is line-boundary-aware even though the budget itself is counted in characters.

3.4 Auto-scroll / "stick to bottom" — IsAtVerticalEnd + ScrollToPosition

UIElement_Text::IsAtVerticalEnd @0x00469350:

00469350  uint8_t __fastcall UIElement_Text::IsAtVerticalEnd(class UIElement_Text* this)
00469350  {
              lineCount = this->m_glyphList.m_glyphList._num_elements;
00469359      if (lineCount == 0)
                  return 1;                                   // empty log counts as "at end"
00469360      lastLineIndex = lineCount - 1;
00469369      return UIElement_Text::IsPositionInView(this, &lastLineIndex);
00469350  }

This is not a scroll-offset comparison — it is "is the last line currently visible inside the viewport right now." IsPositionInView is the same hit-test the widget uses for click-to-position, applied to the transcript's own final line.

RecvNotice_DisplayFinalStringInfo captures this before appending the new line, then decides what to do with it after appending and truncating:

004f46d3          ebx = UIElement_Text::IsAtVerticalEnd(this->m_chatLog);   // BEFORE the new line lands
                   … append prefix, append body, truncate if over budget (§6, §3.1) …
004f4723          if (ebx != 0)
004f4723          {
004f4732              UIElement_Text::ScrollToPosition(m_chatLog, currentLineCount);   // re-stick to the new bottom
004f4739              return;
004f4723          }
004f4723          else
004f473c              this->m_chatNewNonVisibleTextIndicator->vtable->SetState(1);     // flag "unseen text" instead

So: if the user was already looking at the bottom of the log, retail scrolls the new line into view (sticky-bottom). If the user had scrolled up into history, retail does NOT move their scroll position at all — it instead lights the "new unseen text" indicator. There is no separate manual "scroll lock" toggle; this automatic per-line check IS retail's scroll-lock mechanism. m_chatNewNonVisibleTextIndicator is a real UIElement* field (acclient.h:54906), bound in PostInit from element id 0x1000048C — the 16×16 button the window-shell doc's layout dump already placed at (21,62) in the main window and (5,169) in the floaties, labeled there "new-unseen-text indicator (Button)" from the authored rect alone; this document supplies the code that drives it.

3.5 Clearing the unseen-text flag

ChatInterface::ListenToElementMessage @0x004F51C0, click-message case, idElement == 0x1000048c:

004f51f1              if (idElement == 0x1000048c)
004f51f1              {
                           if (m_chatEntry_or_chatLog != 0)      // see field-shift caveat below
004f5208                      UIElement_Text::ScrollToPosition(transcript, transcript->lineCount);
004f520d                      indicator->vtable->SetState(0xd);
                       }

Field-attribution caveat: this function's local variable is BN-named m_chatEntry at the point it calls ScrollToPosition, but the object it scrolls is described by _num_elements of its own m_glyphList — the transcript's own line count, not the chat-entry input field's. Combined with the ctor/struct order (§1.1) and the same-class shift already documented in the window-shell doc for PostInit, the operation this really performs is: clicking the unseen-text indicator scrolls the transcript to its own bottom and resets the indicator's own visual state (SetState(0xd), a different state than the "flagged" SetState(1) set when new text arrives while scrolled up) — i.e. clicking it is the user's manual "catch up" action, and it un-flags itself. Not independently re-verified via cdb; treat the exact numeric visual STATE values (1 vs 0xd) as confirmed, but the specific field bound to "which object gets scrolled to bottom" as inferred from the semantics of IsAtVerticalEnd elsewhere, not a literal read of this function's own variable names.

---

4. Window chrome & interaction

Fully covered by the window-shell doc §1 and §2–§4 — not re-derived here. Summary pointers:

• Move/resize: eight authored UIElement_Resizebar (type 9) grips per window with per-grip bool properties 0x2A/0x2B/0x2C/0x2D (bottom/left/right/top); the main window's plain top edge strip is a UIElement_Dragbar (type 2, move-only) rather than a ninth resize grip — window-shell doc §2.1/§2.3, UIElement_Resizebar::StartMouseResizing @0x0046B7E0.
• Docking/anchoring: none found — windows are free-floating, clamped to stay on-screen only at restore time (gmFloatyMainChatUI::MoveTo @0x004D2D10:004d2d53-004d2dbb).
• Opacity: two GLOBAL floats (Option_DefaultOpacity_Property 0x10000080 unfocused, Option_ActiveOpacity_Property 0x10000081 focused), applied to the WHOLE composited window surface including text via one SetOpacity call — window-shell doc §3, ChatInterface::SetOpacity @0x004F3120. Per-class constructed starting values differ (main window 1.0/1.0 always-opaque, floaties 0.5/1.0) until a saved option overrides them. Retail eases toward the target at 5%-of-delta per tick (ChatInterface::ListenToGlobalMessage @0x004F3840); acdream currently snaps (AP-190, window-shell doc §3.1).
• Show/hide: authored elements toggled via SetVisible, driven by either a keybind (Alt+1..4 for the floaties) or a generic registered-action click dispatch — window-shell doc §1.3/§1.4.
• Persistence: two independent paths — the per-window GameplayOptions blob (position/size/visible/title, gated on m_eWindowID != 0, i.e. the main window's geometry is NEVER saved this way) and a separate local screen-layout text file that IS the only path persisting the main window's geometry — window-shell doc §4.

One piece of chrome not covered by the window-shell doc — the talk-focus menu (main window only):

gmMainChatUI::InitTalkFocusMenu @0x004CDC50 builds a dropdown menu (from the button/group pair at elements 0x10000014/0x10000015, window-shell doc §2.1) with a squelch-toggle entry plus 13 target items, each carrying an Enum attribute 0x1000000B set to a distinct small integer (1 through 0xD) that records which "talk focus" (broadcast target category) that menu row represents:

004cdcd3      this->m_pSquelchToggleButton = UIElement_Menu::AddTextItem(eax_1, &var_90);
… (13x) …
004cdcfb      UIElement::SetAttribute_Enum(eax_3, 0x1000000b, 5);
004cdd07      SmartArray<UIElement_Text *,1>::push_back(&this->m_aTalkFocusButtons, &var_94);

gmMainChatUI::EnableSelection @0x004CE0A0 toggles individual rows' enabled/greyed state (SetState(0xd) when Olthoi-locked); a companion RecvNotice_SelectionChanged @0x004CE050 re-syncs the menu's currently highlighted target whenever the player's WORLD selection changes (via ACCWeenieObject::selectedID and PublicWeenieDesc::IsTalkable) — this is a world-object selection feed (F1-click on an NPC), not a transcript text-tag click, and is out of this document's lane beyond noting that the main window's talk-focus button exists and is driven from it. Only the main window has this menu; floaty windows (window-shell doc §2.2) have neither a talk-focus menu nor a max/min button, only a title bar and close button.

---

5. Tabs / multiple windows

Fully covered by the window-shell doc §1.1–§1.4, §2, §4.1 — not re-derived here. Summary:

• There is no "tab" widget. The five windows (§1.1) are five separate, independently positioned/sized/opaque floating panels, not tabs of one container.
• Creation: none — all five exist from gameplay-UI construction; users cannot create additional windows. Naming: each floaty window has an editable title (gmFloatyChatUI::SetWindowTitle @0x004CEAA0, persisted option 0x1000008D) but the SET of windows is fixed at five; there is no "new chat tab" affordance analogous to modern MMO UIs. Closing: floaty windows close via their own title-bar close button (gmFloatyChatUI::ListenToElementMessage @0x004CE330, element 0x1000052A) or the Alt+N toggle; the main window cannot be closed at all (no close button is authored on it — window-shell doc §2.1's element table has none). Switching: there is no focus-cycling shortcut found; each window is an independent, simultaneously-visible panel, and "switching" only means moving keyboard focus into a different window's entry field by clicking it (which is what drives the opacity fade, §4/window-shell doc §3).
• Per-window state: m_eWindowID, m_llTextTypeFilter (§2), DefaultOpacity/ActiveOpacity (global, not per-window — window-shell doc §3 correction), position/size/visible/title (§4), and the transcript itself (m_chatLog, independently truncated per §3 — each window keeps its own scrollback, so a floaty showing only Tells has its own 10k/7.5k character budget separate from the main window's).
• The main window's four indicator buttons (0x10000522-0x10000525) mirror the four floaties' visibility as one-directional state indicators, not a tab strip — window-shell doc §1.4.

---

6. Timestamps, prefixes, and line composition order

6.1 The two-part composition model — confirmed structurally

ClientSystem::AddTextToScroll @0x00563C50 is where a body string (arg2), a LogTextType (arg3), a plugin-hook flag (arg4) and a windowId (arg5) become the two StringInfo arguments RecvNotice_DisplayFinalStringInfo receives. Its structurally relevant branch (client-local 0x1A short-circuits both the timestamp AND the local log file):

00563de6      if (arg3 == 0x1a)
00563de6      {
                  // build body-only StringInfo, EMPTY prefix StringInfo
00563f2b          ECM_UI::SendNotice_DisplayFinalStringInfo(arg3, &bodyOnly, &emptyPrefix, windowId);
00563de6      }
00563de6      else
00563de6      {
00563dfb          if (PlayerModule::DisplayTimeStamps(&playerModule) != 0)
00563dfb          {
00563e24              wcsftime(&buf, 0x400, u"%#H:%M:%S ", localtime(&now));   // "H:MM:SS " — no date, trailing space
00563e39              PStringBase<unsigned short>::set(&prefixBuffer, &buf);
00563dfb          }
                   … if (s_pLogFile) fprintf(s_pLogFile, "%ls%ls\n", prefixBuffer, bodyBuffer);   // §7.4
              }

There is exactly ONE structural prefix element: the timestamp, and it is entirely optional (gated on PlayerModule::DisplayTimeStamps(), a character option toggle backed by PlayerModule::options2_ bit 6 — PlayerModule::DisplayTimeStamps @0x005D39B0: return (options2_ >> 6) & 1). There is no separate structural "channel name" prefix element ([Fellowship], [<name>], etc.) anywhere in this function or in RecvNotice_DisplayFinalStringInfo. Channel-name brackets that DO appear in retail's transcript (documented already, by content not structure, in the color-table doc §3.3's channel-bit table) are baked directly into the arg2 body string by the SENDING handler (e.g. Handle_Communication__ChannelBroadcast) before it ever reaches AddTextToScroll — from this function's point of view there are only ever two composed parts: prefix (timestamp-or-empty) and body.

6.2 The append order — separator, then prefix, then body

Back in RecvNotice_DisplayFinalStringInfo @0x004F4640 (full body, per the excerpts in §1.2/§3.1/§3.4 stitched together in call order):

004f467c          if (this->m_chatLog->m_glyphList.m_glyphList._num_elements > 0)
004f4687          {
004f469a              UIElement_Text::AppendTextWithFont(this->m_chatLog, L"\n", 0, arg2 /*type*/);
004f467c          }                                                        // 1. separator (skipped on the very first line)
004f46d3          ebx = UIElement_Text::IsAtVerticalEnd(this->m_chatLog);   // captured BEFORE any of the below
004f46dc          if (StringInfo::IsValid(arg4, 1) != 0)
004f46e9              UIElement_Text::AppendStringInfoWithFont(this->m_chatLog, arg4 /*prefix*/, 0, 0xc);
                                                                             // 2. timestamp prefix — ALWAYS color idx 0x0C (grey), only if valid/non-empty
004f46fc          UIElement_Text::AppendStringInfoWithFont(this->m_chatLog, arg3 /*body*/, 0, arg2 /*type*/);
                                                                             // 3. body — colored by the wire LogTextType

Fixed structural order: [\n if not first line] → [timestamp, if enabled] → [body]. The leading separator is a property of the LOG (inserted once per new entry, before the entry, so the transcript never starts with a blank line), not a property of the entry itself — a port that appends body + "\n" per-line instead of "\n" + body will still LOOK identical on screen but will behave differently under TruncateChatLog's newline-boundary search (§3.2) and under IsAtVerticalEnd line-counting (§3.4) if the two approaches disagree at the very first/last line. The color assignment itself is the color-table doc's territory (not re-derived here) — the load-bearing NEW fact this document adds is the order and that the timestamp is unconditionally color index 0x0C regardless of the body's own type, which the color-table doc §3.2 already states from the same address; this document supplies the surrounding append sequence and confirms the timestamp's StringInfo is arg4, always appended strictly BEFORE the body arg3, never interleaved or after.

6.3 Timestamp format, verbatim

u"%#H:%M:%S " fed to wcsftime — hour without a leading zero, minute, second, no date, one trailing space baked into the format string (explaining why no separate space-insertion code exists between prefix and body — the prefix string itself carries its own trailing separator).

---

7. Other user-visible window behaviors

7.1 Local session log file — a port would miss this

ClientSystem::s_pLogFile — a plain-text file retail writes chat lines to during the session, independent of the on-screen transcript's 10k/7.5k character budget (§3.1) or any window's filter (§2). Written from the same AddTextToScroll branch that builds the on-screen timestamp (§6.1):

00563e5b          fprintf(ClientSystem::s_pLogFile, "%ls%ls\n", prefixBuffer, bodyBuffer);

Client-local type 0x1A text (§6.1's short-circuit branch) explicitly bypasses this — client-local errors/refusals never reach the log file, only the on-screen transcript. UNKNOWN — needs further grep: the log file's path/naming convention and whether it rotates per-session or per-character; not chased further as it's a filesystem-artifact question more than a window-UI one, but flagged because "retail also writes a plain-text chat log to disk" is exactly the kind of behavior a UI-only port would miss entirely.

7.2 Unread/unseen marker — confirmed, see §3.4/§3.5

The 0x1000048C "new unseen text" indicator button IS retail's unread marker. It is per-window (each ChatInterface owns its own m_chatNewNonVisibleTextIndicator), lights when a broadcast/addressed line arrives while the user has scrolled away from the bottom, and clears when the user clicks it (which also snaps the transcript back to its bottom). There is no separate "flash the window" or "flash the taskbar/app icon" — FlashWindow/FlashWindowEx do not appear anywhere in the pseudo-C dump (checked via a whole-file grep; zero hits).

7.3 Sound cues on incoming chat — UNKNOWN, likely none dedicated

A targeted grep for PlaySound/SoundManager::Play* near the Handle_Communication__HearDirectSpeech @0x005715A0 (incoming tell) handler body found no sound-manager call inside it, and no Sound_*-named constant resembling "tell received" or "chat" turned up in the identifiers swept. The one chat-adjacent audio-related symbol found is a global preference — Sound_PlaySoundOnlyWhenActive / ID_Sound_NoFocusNoSound (UIPreferences::AttachPreference @0x004037E4, SoundManager::PlaySoundInternal @0x0054FEC0 checks SoundManager::s_bPlaySoundOnlyWhenActive against Device::m_bIsActiveApp) — which mutes ALL UI sounds (not specifically chat) when the game window isn't the active app. UNKNOWN — needs a deeper sweep or a live cdb capture on an incoming tell: this document did not find a chat-specific sound cue, but a negative grep result over a 66 MB pseudo-C dump is weak evidence of absence given how many code paths route through indirect vtable calls the text search can't follow. Flagging rather than asserting "retail has no tell sound."

7.4 Copy/paste and text selection — a base UIElement_Text capability

UIElement_Text::GetSelection @0x00466F20 and UIElement_Text::SelectAll @0x004678D0 exist as capabilities of the general text-widget class that BOTH the chat entry field (m_chatEntry) and the read-only transcript (m_chatLog) are instances of (acclient.h:54904-54905, both typed UIElement_Text*). SelectAll's call sites found are mostly OTHER text-entry fields (a character-name box, a stack-size entry box) triggered by a "select-all-on-first-click" attribute (UIElement::GetAttribute_Bool(this, 0xd1, ...) inside UIElement_Text::MouseDown @0x00469370), not anything chat-specific. UNKNOWN — not independently confirmed for the read-only transcript specifically: whether the transcript panel exposes the SAME click-drag-select-then-copy affordance as the entry field, or whether it is flagged read-only in a way that suppresses selection; the class-level capability clearly exists on the type, but no chat-transcript-specific selection code path was located distinct from the generic UIElement_Text mouse-down handler already cited. Worth a live-client check (select text in the retail transcript, see if a selection highlight appears) rather than further static digging.

7.5 What's genuinely absent

• No FlashWindow anywhere in the binary (§7.2).
• No docking/snapping between chat windows or to screen edges — the window-shell doc's resize/move research found only free-floating clamped-on-restore positioning (§4).
• No tab strip / tabbed-window container (§5) — five independent panels, not a tab model.
• No manual "scroll lock" toggle — the auto-scroll behavior in §3.4 IS the scroll-lock mechanism, driven automatically by IsAtVerticalEnd, with no user-facing on/off switch found.

---

Behaviours acdream is most likely missing

Ordered by how load-bearing each gap looks against RuntimeCommunicationState (docs/research/2026-07-26-slice-j4-1-communication-state.md) and ChatWindowController as of this session:

1. Scrollback truncation entirely. No 10,000-char trigger / ~7,500-char target / newline-boundary-preferring trim (§3.1–§3.3) appears to exist in acdream today — grep TruncateChatLog-equivalent behavior in ChatLog/ChatWindowController before assuming an unbounded transcript is fine; it will diverge from retail under long play sessions (memory growth) and, more subtly, under the exact wrap point if a port ever needs pixel/line parity with a retail screenshot at high message volume.
2. The auto-scroll / stick-to-bottom vs. flag-unseen-instead split (§3.4–§3.5). This is a genuine behavioral fork, not a cosmetic one: a naive port that ALWAYS scrolls to bottom on new text will yank the user's scroll position out from under them mid-read whenever a broadcast line arrives — exactly the annoyance retail's IsAtVerticalEnd check exists to prevent. Confirm ChatWindowController checks "was I at the bottom before this line landed" before auto-scrolling, and confirm the 0x1000048C unseen-indicator element (window-shell doc's layout dump already has its rect for both window layouts) is wired to light up + clear via click exactly as §3.4/§3.5 describe.
3. The window-ID routing predicate as ONE explicit rule (§1.2). The color-table doc already flags the routing behavior; this document adds the exact decompiled shape. Verify RuntimeCommunicationState's chat windows model (per the CH6c plan in the window-shell doc §6.1) implements precisely windowId == m_eWindowID || (windowId == 0 && TypeIsActive) — not, e.g., "every window with the type enabled shows every line regardless of address," which would make addressed command-output lines leak into windows they were never meant for.
4. Structural composition order (§6.2) — separator-before-entry (not after), timestamp-before-body, timestamp always present-or-absent as a single unit gated on one option bit. A port that concatenates timestamp + " " + body as one string loses retail's separately-colored, separately-truncatable prefix run and the option-driven all-or-nothing presence.
5. The local session chat-log file (§7.1). Small, but "retail writes a plain-text transcript to disk every session" is the kind of feature users notice is missing only when they go looking for it after the fact.
6. Per-window independent scrollback. Once §1 is implemented, confirm each of the five windows truncates its OWN transcript independently (§5) rather than sharing one global buffer — a floaty window filtered down to just Tells should never truncate early just because the main window's transcript is huge.
7. Sound cues and transcript text-selection are open questions, not confirmed gaps (§7.3, §7.4) — do not build negative-result "retail has none of this" code around them; re-check live if/when they become relevant.