fix(chat): BuildTell wire field order + retail-style FormatEntry + suppress duplicate Channel echo

Three follow-up fixes from the 2026-04-25 live verify session.

1. CRITICAL: BuildTell wire field order. Our outbound layout was
   [target_name, message] but ACE's GameActionTell.Handle reads
   [message, target_name] (verified against
   references/ACE/.../GameActionTell.cs:17-18 verbatim). Result: every
   /tell since Phase I.3 has been failing with WeenieError 0x052B
   (CharacterNotAvailable) because ACE was looking up the message
   text as the recipient name. Swapped the field order in
   ChatRequests.BuildTell so message is written first; updated the
   pinned BuildTell test to expect the corrected layout. The
   WorldSessionChatTests round-trip continues to pass since SendTell
   delegates to BuildTell.

2. Retail-style FormatEntry. The user asked for the canonical retail
   strings:
     /say (own):       You say, "text"
     /say (incoming):  Name says, "text"
     /tell (own echo): You tell Caith, "text"
     /tell (incoming): Caith tells you, "text"
     channel:          [Trade] +Acdream says, "text"
     /shout (own):     You shout, "text"
     /shout (incoming):Name shouts, "text"

   Discriminators: SenderGuid == 0 distinguishes our own outbound
   echoes (set by OnSelfSent) from real incoming whispers (carry the
   sender's player guid). Sender == "" or "You" distinguishes our own
   /say echoes (OnLocalSpeech substitutes "You" when the wire sender
   is empty per holtburger client/messages.rs:476-487).

   ChatEntry gains a new ChannelName slot so Channel-kind entries
   render with the friendly room name ("Trade") instead of "ch 3".
   Falls back to "ch {ChannelId}" when ChannelName isn't populated
   (legacy ChatChannel inbound or older callers).

3. Suppress optimistic Channel echo. The user saw duplicates per
   /trade /lfg in the live trace:
     [ch 0] Trade: hello                     <-- our optimistic
     [ch 3] +Acdream: [Trade] hello          <-- ACE's TurbineChat broadcast
   ACE's TurbineChatHandler at Network/Handlers/TurbineChatHandler.cs
   broadcasts EventSendToRoom to ALL recipients in the room including
   the sender, so the canonical echo always arrives via 0xF7DE. Drop
   the optimistic OnSelfSent for Turbine kinds in GameWindow's
   SendChatCmd handler; trust the server. Legacy ChatChannel paths
   (Fellowship / Allegiance / Patron / Monarch / Vassals / CoVassals)
   keep the optimistic echo because the legacy 0x0147 broadcast may
   not always come back to the sender.

   Inbound TurbineChat also stops embedding "[Trade] " into the
   message text — passes the friendly name out-of-band via the new
   channelName parameter on ChatLog.OnChannelBroadcast.

11 tests updated for the new format strings (8 in ChatVMTests, 1 in
ChatVMCombatTests, 1 BuildTell, plus the format additions cover
incoming/outgoing variants per kind). Solution total: 1007 green
(243 + 114 + 650), 0 warnings.

Tells should now actually deliver. Channel echoes show as
[Trade] +Acdream says, "hello" without the duplicate.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik 2026-04-25 20:49:02 +02:00
parent e17caa2942
commit 3f7821c18d
7 changed files with 204 additions and 47 deletions

View file

@ -1258,15 +1258,22 @@ public sealed class GameWindow : IDisposable
{
if (parsed.Body is AcDream.Core.Net.Messages.TurbineChat.Payload.EventSendToRoom ev)
{
// Pass the friendly channel name out-of-band via
// ChatLog.OnChannelBroadcast's channelName param so
// ChatVM.FormatEntry can render the retail-style
// "[Trade] +Acdream says, \"hello\"" without us
// mangling the payload text.
string label = TurbineRoomDisplayName(ev.RoomId, ev.ChatType);
Chat.OnChannelBroadcast(
channelId: ev.RoomId,
sender: ev.SenderName,
text: $"[{label}] {ev.Message}");
channelId: ev.RoomId,
sender: ev.SenderName,
text: ev.Message,
channelName: label);
}
// Response (server ack of an outbound RequestSendToRoomById)
// and Unknown payloads are intentionally not surfaced — the
// user already saw their optimistic local echo.
// and Unknown payloads are intentionally not surfaced —
// the inbound EventSendToRoom for our own message acts as
// the canonical echo.
};
// Phase I.3: real ICommandBus. Panels publish SendChatCmd here
@ -1302,6 +1309,14 @@ public sealed class GameWindow : IDisposable
// Allegiance is double-routed: try TurbineChat first
// (when the player has a Turbine allegiance room) and
// fall back to the legacy 0x0147 ChatChannel.
//
// We do NOT optimistic-echo channels: ACE's
// TurbineChatHandler broadcasts EventSendToRoom back
// to the sender too, so we always get the canonical
// echo from the server. Optimistic-echoing here
// double-prints the message (one as "[Trade] hello"
// from us, one as "[Trade] +Acdream says, \"hello\""
// from the server). Trust the server.
var turbine = ResolveTurbineForKind(cmd.Channel, turbineChat);
if (turbine is not null)
{
@ -1323,9 +1338,10 @@ public sealed class GameWindow : IDisposable
senderGuid: senderGuid,
text: cmd.Text,
cookie: cookie);
chat.OnSelfSent(
AcDream.Core.Chat.ChatKind.Channel, cmd.Text,
targetOrChannel: turbine.Value.DisplayName);
// No optimistic echo: server EventSendToRoom
// broadcast comes back with sender="+Acdream"
// and is rendered by ChatVM as
// "[Trade] +Acdream says, \"hello\"".
break;
}
@ -1347,6 +1363,12 @@ public sealed class GameWindow : IDisposable
$"chat: outbound legacy ChatChannel {resolved.Value.DisplayName} " +
$"id=0x{resolved.Value.ChannelId:X8} len={cmd.Text.Length}");
liveSession.SendChannel(resolved.Value.ChannelId, cmd.Text);
// Legacy channels (Fellowship / Allegiance / Patron /
// Monarch / Vassals / CoVassals) — keep the optimistic
// echo because legacy ChatChannel does NOT always
// broadcast back to the sender. ChannelName is the
// friendly display name so ChatVM renders it as
// "[Fellowship] +Acdream says, \"hello\"".
chat.OnSelfSent(
AcDream.Core.Chat.ChatKind.Channel, cmd.Text,
targetOrChannel: resolved.Value.DisplayName);