User:Moonmoon/multiclient

When multiple clients are in use, recommend the following behaviors:

• Main client is the only one opped (+o) in the game channel, and is responsible for all channel messages. No users are assigned to this client for private messages.
  • This lets the list of voiced (+v) users, aka alive players, to still prominently show in the user list vs all bot clients being opped and pushing the voiced list down further in client displays
  • By having the main client not handle PMs at all, we close off potential exploits where a user keeps the main client busy in PM, thus delaying a -v when killing a dead player and allowing hints or other communication that should not otherwise happen
• Secondary clients are assigned to players somehow so that in the course of a single game (or perhaps longer), there is a consistent client that the player can communicate with
  • This helps prevent the proliferation of PM windows on the client, so the player does not accidentally miss bot PMs and does not need to navigate through as many windows when jumping between bot PM and main game channel.
• Despite the secondary client assignment, it may be possible for a different client to reply (that was not the assigned client), depending on a few factors:

User sends a	To the	With their !notice setting	The bot client which responds is	via
PRIVMSG	Main client	Enabled	Assigned client	NOTICE
PRIVMSG	Main client	Disabled	Assigned client	PRIVMSG
PRIVMSG	*	Enabled	Assigned client	NOTICE
PRIVMSG	*	Disabled	The messaged client	PRIVMSG
NOTICE	*	*	Assigned client	NOTICE

• If a NOTICE is sent to the client, a NOTICE is always sent back; this workflow is for those clients which do not open new windows upon receiving notices, instead putting them into a relevant shared window (aka the game channel)
• Main client never responds to private commands per reasoning above
• If a PRIVMSG is sent to a secondary client and !notice is off, we assume that client-side a window was opened for that message, so we want to reply in the same window to keep things together and help ensure the user doesn't miss anything
• If a PRIVMSG is sent to the secondary client and !notice is on, we behave as if a NOTICE was sent instead, as !notice being on usually indicates that the client is not going to be opening new PM windows. As such, keep the load balancing intact as much as possible by sending from the assigned client.