Hiding chat commands with /e no longer works

[Dimenpsyonal]

Version channel

Stable (Default)

Loader version

v271

What part of Adonis is this related to?

Loader/Settings

What happened?

Chat commands that are hidden in chat using /e :somecommand are no longer executed due to a recent change by Roblox regarding the Player.Chatted behaviour, which is now only fired if the message is visible.
To fix this, I reccomend that the chat command behaviour should be checked using the new TextChatService system.

Roblox's explanation:

Here is my current assumption of what is occurring based on the information I have so far:

    We have recently made changes to Player.Chatted to better support it long term. Previously this fired outside of TextChatService, however we have integrated it within TextChatService to solve issues like [this](https://devforum.roblox.com/t/playerchatted-not-firing-on-the-client-for-the-local-player-with-textchatservice/3652658) and [this](https://devforum.roblox.com/t/playerchatted-event-firing-on-the-client-on-messages-the-player-wouldnt-normally-see-in-textchatservice/2506305) and allowed unmaintained tech debt to be scheduled for removal.
    Existing code was written that for custom commands that conflicted with the default TextChatCommand /emote. Previously, since Player.Chatted was not properly integrated in TextChatService, it was not aware when a raised signal was going to be “sunk” by a TextChatCommand triggering. This was causing Player.Chatted to raise even though messages were not being delivered.
    Now that Player.Chatted fires more “accurately” within TextChatService, messages that arent actually delivered (such as TextChatCommands triggering, invalid privacy settings, or invalid TextChannel permissions) are no longer raising the Player.Chatted command as often as it used to.
    While this makes Player.Chatted more “accurate” (it only fires when a message is sent + delivered to count as a “Chatted”), it broke this assumption that all “sent” messages were to raise Player.Chatted even if they were never actually delivered or seen.

Player.Chatted is an older API and it is apparent to those who learn that [its second parameter, recipient has been marked deprecated on the API documentation](https://create.roblox.com/docs/reference/engine/classes/Player#Chatted). It has been superseded by APIs such as TextChatService.MessageReceived and TextChannel.MessageReceived which provides more context on the sent messages.

There appears to be some overlap with the current usecase to support custom emotes via Player.Chatted. For the best longterm support, my recommendation would be to leverage TextChatCommand.Triggered to handle any custom emotes. The reason this is an issue right now is sent messages are being “sunk” when they trigger a [TextChatCommand](https://create.roblox.com/docs/reference/engine/classes/TextChatCommand).
The default RBXEmoteCommand currently has an alias assigned to /emote and /e`.

Without reverting to previous Player.Chatted behavior, I see two ways to remedy:

1.    (Recommended) Extend RBXEmoteCommand functionality by binding to it’s Triggered event

--!strict
-- LocalScript / RunContext = Client
local TextChatService = game:GetService("TextChatService")
local Players = game:GetService("Players")
local EmoteCommand = TextChatService:WaitForChild("TextChatCommands"):WaitForChild("RBXEmoteCommand")
assert(EmoteCommand:IsA("TextChatCommand"), "expected RBXEmoteCommand to be a TextChatCommand")

EmoteCommand.Triggered:Connect(function(originTextSource, messageString)
	local player = Players:GetPlayerByUserId(originTextSource.UserId)
	if player then
		-- paste your existing .Chatted code here using player and messageString
		print(player, messageString)
	end
end)

2.    Destroy or set RBXEmoteCommand.Enabled to false to permit delivering messages that start with /e. This is less recommended as it will then send those messages to all other recipients which is likely unwanted.

Steps to reproduce

NA

Device

Windows

Relevant log output