Player.PlayerChatted is an event used by the chat CoreScript. It handles regular chat, whispering, and team chat, and doesn’t require to be connected to every player, and gives you the player, message, and target player.
We have no other way to monitor whisper or team chat, unlocking it would be nice.
15 Likes
*caugh* keylog *caugh*
support
what
9 Likes
Keylogging? Okay I support!
4 Likes
a custom chat with custom input can also solve this issue as i did with mine.
He probably means use UserInputService to get keystrokes and then you can just parse that with string patterns to get whisper chats etc.
Gonna bump this because there’s no way to get when a player uses teamchat / whispers 
yes please, no reason this should be locked.
1 Like
Whispers are kind of private (or at least I would expect them to be if I were using them) so I wouldnt expose those to the server.
Team chat is fine though (just make sure to not break some game by suddenly starting to send team chat to the same event as normal chat - it might be better as a separate event to avoid this).
In my opinion, what should the user hide in terms of chat to the server/game? We can already catch +/- all their input if they start chatting (except some characters for now) with some ‘key logging’.
And this event cannot be used by anything outside the CoreScripts or the CommandBar in Studio right now so making yet another function when this is unlocked wouldn’t be needed in my opinion. Unlocking this would help people a lot for making custom Chat GUIs without the need to remake the ChatBar. (Making a so called ‘key logger’ to detect teamchat is not possible right now due the already mentioned issue above)
I mean dont suddenly start pushing whispers into player.Chatted (even if an extra argument was passed to the listening function to indicate its team/whisper, old scripts wont take that into account)
Its not nice if all your whispers are publicly displayed by some custom chat GUI, because the creator didnt update the script or messed something up.
Whispers are assumed to be private, so people will use it for private communication. Sure its possible to capture them and make them public if you really explicitly try to. Just dont make it something that happens accidentally because the developer didnt take into account an optional “ChatType” parameter in their event handler…
Plus I see zero reason for the server to ever read whisper contents, unless directed at the server somehow.
1 Like
Just made a (not so pretty) solution to this:
Unfortunately it will only work for players who have the same keyboard layout as me (UK) however if it’s really important to a game then you could make the player select their keyboard layout before they play and use different enumToChar dictionaries depending on the layout they use.
We’re not talking about Player.Chatted, we’re talking about PlayerChatted, an event in Players
I assumed the ability to capture team/whisper chat would be added to player.Chatted as well for consistency. Even if it was only added to PlayerChatted, still need to be careful with them whispers.
Whispers have to go through some event, else they’ll never show up in the chat.
Does PlayerChatted only work on clients? And only get whispers if theyre directed to that specific player? That would be the only situation where its ok to just identify them with a parameter.
It works on both the server and client AFAIK, also, I don’t see any reason whispers should be hidden from the server, it’s exceedingly easy to get what they’re typing and the whisper has to go client > server > client anyway so there’s no point in not having it call it server side
The privacy of whispers should not rely on random developers bothering to check the “chatType” parameter the event passes. Its just bad design.
Either the developer must express explicit interest in whispers (a separate event for whispers is one way to implement that), or they shouldnt be easily available at all.
Im not trying to stop developers getting whispers if they really want to (though it would be better if this was not possible). There simply is zero legitimate use cases that I can see for getting whispers of users to other users, so the disadvantages of exposing them through an easy-to-misuse interface outweigh the advantages.
There has to be a way to get whispers, else custom chats would not work.
As far as I’m concerned, you’re being far too paranoid, if you see a certain developer hasn’t implemented whispers correctly you can simply not whisper, and if something does get out, you’re not exactly going to be sharing government secrets within a roblox game
There only has to be a way for clients to get whispers, directed specifically at that client.
I acknowledge that this is a minor issue, but I dont see any reason NOT to implement the interface in a way that acknowledges the privacy of whispers (because thats what users are led to believe). Just make the event not receive whispers if its serverside (and client only receive whispers directed to them). Or push the whispers through a separate event. Who knows, maybe it already works like that.
Im just thinking of that one person whispering me “want free robux?”. Im sure they would feel bad if that was shown to the whole server.