fix(chat): round 4 — no user-visible meta text, real /help groups, indicator buttons toggle
Item 3 (#364): every honesty marker is now gone from user-visible /help text. AllegianceOverview/HouseOverview's "[IMPLEMENTED]" tags and trailing "Subcommands NOT marked..." sentences, and Day/Log/Render/Motd's appended "NOT YET IMPLEMENTED in acdream" tails, are removed; the underlying retail text is corrected/completed against the pseudo-C's own pristine consolidated data dumps (Log and Motd had been silently truncated; Render was entirely acdream-authored and is replaced with the real retail usage string). The three PARTIAL /help group topics (channels/chatting/commands) are now COMPLETE verbatim listings: HelpStupidChannelHack's three "vtable slot" operands, previously believed undecodable, are the same pooled/mislabeled-data artifact this campaign has hit before (AP-113's precedent) — reading the function's own disassembly for the push imm32 preceding each constructor call resolves all three directly. messagetypes is now a real ported construction (IsLegalChannel's 14-id whitelist + LogTextTypeToString's name table + the exact join/wrap format) instead of an acdream summary. Register row AP-184 retired. Item 5: the main window's 1/2/3/4 indicator buttons now toggle their floating chat window on click, per the user's retail memory overruling the earlier decomp-only reading. UIElement_Button::HandleButtonClick has its own generic click-driven action dispatch (property 0x12) reaching the same DoVisibilityToggleAction the Alt+1..4 keybinds use; the button fixture confirms this half is genuinely armed, but the floating-window fixture authors no matching listener-registration property, so the generic mechanism has no proven target in the data on hand. Per CLAUDE.md, the user's retail memory is the axiom regardless: ChatWindowController.BindIndicatorClicks wires each indicator's click through the same ToggleFloatingChatWindow chokepoint the keybinds use, as explicit user-directed retail behavior. SetIndicatorOpen stays the sole writer of the Selected mirror so the visual stays consistent through the click round trip. Full reconciliation in docs/research/2026-08-09-chat-retail-window-shell.md §1.4. Campaign plan gets the round-4 findings section; items 1+2 (text-style) are under parallel research, item 4 passed, item 6 deferred to the settings track. Suite: 12,579 passed / 4 skipped / 0 failed (Release, complete solution), up from baseline 12,553/4/0 — net +26 tests, zero regressions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik
parent
8b166f3ea2
commit
5b54387b8e
10 changed files with 1129 additions and 239 deletions
|
|
@ -382,32 +382,48 @@ user gate round 3; closed in the goal-window follow-up).
|
|||
|
||||
## #364 — Three `/help` group topics still partial: HelpStupidChannelHack unresolved
|
||||
|
||||
**Status:** OPEN — filed 2026-08-09, Campaign CH user-gate round 2, item 3.
|
||||
**Status:** CLOSED 2026-08-10 — Campaign CH round 4. The blocker in the
|
||||
original filing (below) was a wrong belief, not a real limitation:
|
||||
`ClientCommunicationSystem::HelpStupidChannelHack @0x0056f290`'s three
|
||||
"vtable slot" operands are the SAME pooled/mislabeled-data artifact this
|
||||
file's register entry AP-113 already documented elsewhere — real DATA
|
||||
pointers into `.rdata`, not vtable dispatch. Reading the function's own
|
||||
disassembly for the `push imm32` immediately preceding each
|
||||
`PStringBase::PStringBase` constructor call (instead of trusting Binary
|
||||
Ninja's line-grouped rendering, which hides the true instruction order)
|
||||
resolves all three operands directly: the function builds
|
||||
`"@" + tag + " - Sends a broadcast to your " + ChannelName + ".\n"`, where
|
||||
`tag` is one character sliced out of a shared wide literal `U"fvpca"`
|
||||
(reading a WIDE string through a NARROW `char*` truncates at the first
|
||||
zero high byte — the "hack" the function's own retail name calls out) and
|
||||
`ChannelName` comes from `ChannelSystem::GetChannelName`'s own literal
|
||||
switch table (also read directly: "Allegiance", "Co-vassals", "Monarch",
|
||||
"Patron", "Vassals", "Fellowship"). `ChannelsGroupDetail`,
|
||||
`ChattingGroupDetail` (whose "@reply" entry also needed
|
||||
`HelpReply@0x00577A50`'s Summary-branch decoded — it unconditionally
|
||||
concatenates reply+pr+mr, a genuine retail quirk ported as found), and
|
||||
`CommandsGroupDetail` (`HelpAllGroup`, a straight-line concatenation of
|
||||
every other group's Detail branch, including a CONFIRMED retail
|
||||
saveui/loadui duplicate) are now COMPLETE verbatim listings, matching the
|
||||
four (death/status/text/allegiances) already complete. Register row
|
||||
AP-184 RETIRED with the full citation trail. The 5 remaining
|
||||
`ByVerb`-only channel one-liners (fellowship/monarch/patron/vassals/
|
||||
covassal, as standalone `/help f`-style lookups rather than group-listing
|
||||
entries) are UNCHANGED — their own standalone help registration was never
|
||||
confirmed independently of this mechanism, so they are deliberately left
|
||||
as acdream summaries rather than spliced in speculatively.
|
||||
|
||||
**Original filing (2026-08-09, Campaign CH user-gate round 2, item 3):**
|
||||
The user caught `/help death` printing an acdream meta-message instead of
|
||||
retail's real listing; all 7 `ClientCommunicationSystem::HelpXxxGroup`
|
||||
nodes were re-extracted verbatim from the PDB-paired binary via a
|
||||
generalized `tools/pdb-extract/sweep_weenie_strings.py --ascii-only`.
|
||||
4 of 7 (death/status/text/allegiances) are now COMPLETE verbatim listings
|
||||
(`RetailCommandHelpTable.DeathGroupDetail` etc.). 3 remain PARTIAL
|
||||
(`ChannelsGroupDetail`, `ChattingGroupDetail`, `CommandsGroupDetail`):
|
||||
their detail text is built (in full or in part) by
|
||||
`ClientCommunicationSystem::HelpStupidChannelHack @0x0056f290`, which
|
||||
constructs its output from three string fragments Binary Ninja
|
||||
mis-attributes to unrelated vtable slots (the classic BN pooled/
|
||||
mislabeled-data artifact — `&ClientCommunicationSystem::\`vftable'.
|
||||
RecvNotice_StartBarberNotice` etc. are NOT real vtable dispatch)
|
||||
concatenated around a live `ChannelSystem::GetChannelName` call —
|
||||
genuinely not decodable from a static string sweep. Each partial group
|
||||
keeps its own summary line (fully verbatim) and an explicit UNVERIFIED
|
||||
note citing the address; `chatting` additionally resolves 7 of its 8
|
||||
detail entries (only the 5 HelpStupidChannelHack-delegated channel-alias
|
||||
lines are missing). The same mechanism also blocks 5 of ~35 channel
|
||||
one-liners in `ByVerb` (fellowship/monarch/patron/vassals/covassal
|
||||
family), which stay acdream-authored summaries. Resolving
|
||||
HelpStupidChannelHack requires reading the three mislabeled string
|
||||
fragments directly out of `.rdata` by address (not by BN symbol name) and
|
||||
confirming the channel-name substring logic — a focused follow-up, not
|
||||
guessed.
|
||||
4 of 7 (death/status/text/allegiances) were COMPLETE verbatim listings
|
||||
(`RetailCommandHelpTable.DeathGroupDetail` etc.); 3 remained PARTIAL
|
||||
(`ChannelsGroupDetail`, `ChattingGroupDetail`, `CommandsGroupDetail`) with
|
||||
an explicit UNVERIFIED note, believed genuinely not decodable from a
|
||||
static string sweep — see the CLOSED note above for why that turned out
|
||||
to be wrong.
|
||||
|
||||
**Campaign:** `docs/plans/2026-08-09-chat-parity-campaign.md` (Campaign CH,
|
||||
user gate round 2).
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue