feat(discord): Discord integration packets for MuMain

[sven-n]

Packet definitions and server side for the client part of the Discord integration (sven-n/MuMain#696: C2 integration info, C3 link dialog, C4 messages from Discord, C5 guild window). Stacked on #1161 (M5).

Packets (opt-in F5 group, like the chat command list)

Direction	Code	Name	Content
C→S	C1 F5 02	DiscordIntegrationInfoRequest	Empty. Also announces that the client understands ExternalChatMessage.
S→C	C1 F5 03	DiscordIntegrationInfo	Account linked; guild, alliance and world chat bridged; Rich Presence application id and large/small image keys; invite URL; linked Discord user name.
C→S	C1 F5 04	DiscordLinkCodeRequest	Empty.
S→C	C1 F5 05	DiscordLinkCode	Result (Success / NotAvailable), the one-time code (ABCD-EFGH), minutes valid.
C→S	C1 F5 06	DiscordUnlinkRequest	Empty. Answered with a new DiscordIntegrationInfo.
S→C	C2 F5 07	ExternalChatMessage	Source (Discord), scope (Guild / Alliance / World), sender name (48 bytes, not a character), message (variable).

The generated structs, connection extensions, packet docs and packet tests were regenerated from the XML; nothing outside the new packets changed.

Server

• Feature plugin Discord integration of the client (DiscordIntegrationFeaturePlugIn). Its configuration holds what the client gets: InviteUrl, RichPresenceApplicationId, RichPresenceLargeImageKey, RichPresenceSmallImageKey. These are no secrets, since every player can read them. When the plugin is deactivated, clients get an empty integration info and hide their Discord features.

• DiscordIntegrationAction collects the info for a player:

  • the configuration
  • the account link, through AccountLinkService (M4)
  • the guild and alliance chat bindings, the same check as GuildChatBridgeNoticePlugIn
  • whether the world chat is published, i.e. the game event publisher is active with Publish chat messages

  It also creates link codes and unlinks. /discord unlink now uses the same unlink, including the AccountUnlinkedEvent.

• Handlers and view: handlers for F5 02/04/06 in the existing F5 group, plus DiscordIntegrationViewPlugIn. All have MinimumClient(106, 3, Invariant), like the chat command list.

• Messages from Discord: senders bridged from Discord (the @ prefix of M5, now shared as BridgedChatSender; DiscordChatText.DiscordSenderPrefix refers to it) are sent as ExternalChatMessage to clients that asked for the integration info:

  • guild and alliance chat in ChatViewPlugIn, with the chat prefix @/@@ removed
  • world chat in GameServer.WorldChatMessageAsync

  All other clients get exactly what they got before.

• Docs: a "The game client" section on the Discord page, and the plugin on the plugins page.

Limitations

• Sender name: the sender of an ExternalChatMessage is the linked character, as in M5. The Discord display name isn't carried through IEventPublisher yet. The field has room for it (48 bytes).
• World chat flag: "world chat bridged" means the chat is published. The game server can't see whether the bot's layout has a world chat channel.
• Binding channel name: no binding channel name is sent, because GuildChatBinding doesn't store it.

Tests

• Packet tests (generated): 632/632 passed.
• New:
  • DiscordIntegrationViewPlugInTest: packet contents; link code results; external chat only after the client asked; bridged guild message → ExternalChatMessage for supporting clients and unchanged chat for others; character messages stay normal chat.
  • DiscordIntegrationActionTest: deactivated plugin → no info; configuration and link state; unlink.
• Full solution dotnet test: all green (3,377 passed, 11 skipped).

Not tested: against a real Discord bot, or a running MuMain client.

The MuMain side follows as a draft PR in sven-n/MuMain. It needs these packets released in MUnique.OpenMU.Network.Packets before it can build in CI.

🤖 Generated with Claude Code

https://claude.ai/code/session_012feEciycvL8PGjsezyRFqj

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying openmudocs with    Cloudflare Pages

Latest commit:	b4b567d
Status:	✅  Deploy successful!
Preview URL:	https://0be7af58.openmudocs.pages.dev
Branch Preview URL:	https://claude-discord-presence-muma.openmudocs.pages.dev

View logs

[sven-n]

Part of a review pass over the whole Discord stack, including the four client PRs in sven-n/MuMain that consume these packets.

I cross-checked the wire format against the client implementation in sven-n/MuMain#709 (src/source/Network/Discord/DiscordPackets.cpp) and the two agree exactly — ExternalChatMessage at 5/6/7+48/55, DiscordIntegrationInfo at 4/5/6/7/8+20/28+32/60+32/92+100/192+32, DiscordLinkCode at 4/5+10/15. No offset drift.

A few format details I checked and am satisfied with:

• ExternalChatMessage correctly uses C2HeaderWithSubCode, so a long bridged message isn't constrained to a fixed field.
• The capability handshake — the client announcing support by sending DiscordIntegrationInfoRequest, with older clients continuing to get prefixed normal chat messages — is a clean way to avoid a client version bump, and ChatViewPlugIn falls back correctly when the view plug-in isn't present.
• LinkedUserName at 32 bytes exactly matches Discord's maximum username length, so a full-length name leaves no room for a terminator and ends flush with the end of the 224-byte packet. I checked the client side and it's safe — ReadString passes an explicit maxSourceLength to MultiByteToWideChar and terminates the buffer itself, so there's no overread. Worth being aware of if another client implementation ever reads these fields as C strings.

Three comments inline. The two about client-triggered database work are the ones I'd act on; the third is a shared invariant that also affects #1161.

---

Generated by Claude Code