I don’t wanna necropost something, but the /e chat command has once again stopped firing player.chatted in live servers, which was seen as useful for hiding messages from other players or, in the case of the ro-wrestling community, hiding commands or executing taunts like /e raisearms
Expected behavior
Saying “/e …” should fire player.chatted
Can confirm it is in fact not firing player.Chatted when starting a message with /e
Hi, can you provide experiences where this is occuring? Are you checking for .Chatted on from LocalScript or the Server?
Both, really. Some scripts are localscripts, but others are server-side.
/e messages don’t appear for Client or Server scripts, experiences I have tried this in so far are my own game and Find the Chomiks (as I wanted to make sure I didn’t just break something myself)
Here is my current assumption of what is occurring based on the information I have so far:
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 and this and allowed unmaintained tech debt to be scheduled for removal./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.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.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. 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.
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:
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)
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.Could those who are experiencing this issue confirm if my assumptions are correct?
Neither will work in our situation, as there are several scripts that use the /e functionality, particularly to hide stuff from being chatted. Aside from that, the second option does fix the /e commands themselves.
Could you share an experience this is occurring in so I can understand better? My understanding is that Player.Chatted may not be raised because a TextChatCommand is being triggered – and if that is the case the chat already won’t be visible.
However your response leaves me to wonder maybe there’s something else going on.
Keep in mind I recently added a script based on your second option.
Hi thanks for the link. Just to confirm something… are you destroying/disabling the TextChatCommand from the client and server or just the one or the other?
Youll likely want to disable it from the server if you havent.
If you already are I need to investigate further.
I’ve been messing around in the experience linked and it seems even if I locally revert this change the behavior is not “restored” as you expected
I noticed a few /e commands don’t work like /e cena and /e raisearms – with and without the local revert.
However I noticed a few /e commands do work like /e dance and /e drake – again with and without the local revert.
There are other wrestling-based games that use /e commands, not all of them I develop for.
I agree, this bug also still hasn’t been fixed yet for anyone wondering.
Roblox has once again completely broken the Player.Chatted event for messages starting with “/e” commands used by the new TextChatService, which is really annoying for those of us who rely on it for custom emote commands.
In my opinion, Roblox shouldn’t restrict messages this way as Player.Chatted should show exactly what the player typed. Limiting it like this isn’t fair to developers as it reduces our options and flexibility for development.
I additionally noticed that the server no longer receives messages from players that are stopped due to spam. This is inconvenient because I still want to be able to execute admin commands stopped due to spam.
During a stress test on the aforementioned game, I have noticed that the standard chat commands like /e laugh or /e point don’t work, so the solution isn’t a total fix
Additionally, with some of the experiences I work on, the /e chat commands are embedded into server-side scripts, not local ones.
I was able to find a solution by adding the default taunt commands to the script
This is an issue for 2 reasons, one, it breaks existing code, 2 it makes it impossible to silently execute commands on mobile in our fork of Adonis “Superduperdev2 Admin Commands”, With this change, admins cannot silently execute commands on mobile at all, because we don’t have a mobile method for opening the command bar. I would implement that if it didn’t mean having to rewrite large portions of the code. (Artem script moment) The expected behavior is /e should fire .Chatted to keep compatibility with older games and also games that cannot add custom text chat commands without massive rewrites
Its not just /e, any textchatcommand is failing to fire .chatted.
All of my custom scripted commands stopped working in the last few days. I use ‘textchatcommand’ objects to hide the commands from the game chat:
if i don’t use the textchatcommand objects the commands work as expected.
but then the commands show up in the general chat and chat bubbles
The textchatcommand objects seem to be blocking the player.chatted event from firing.
The texchatcommand being triggered used to ALSO fire the Player.Chatted event. Now it does not. I think the order was changed.
before:
player chats…
player.chatted is fired
server checks if textchatcommand was triggered
message is displayed in general chat (if not a textchatcommand)
now:
player chats…
server checks if textchatcommand was triggered
player.chatted is fired (if not a textchatcommand)
message is displayed in general chat (if not a textchatcommand)
this check has been moved in the order:
I fixed mine by just converting to using the textchatcommand.triggered event, but I’m sure a lot of older games or games with no current dev support team will be broken due to this change.
one gotcha to look out for when converting is that the .triggered event doesn’t give you the player like .chatted does, it gives you the textsource object so you have to get the player to send to the function that you had used with .chatted previously:
TextChatCommandObject.Triggered:Connect(function(textsource, message)
local player = game.Players:FindFirstChild(textsource.Name)
if player then
onPlayerChatted(player, message)
end
end)Having the same issues with my experiences, which prioritize /e for chat commands (as it hides the command).