Why do you want this on the server?
You can still create experiences with Legacy but it wonât work, and will get migrated to TextChatService. We are working on removing Legacy Chat as an option within the version for new experiences. Sorry for the delay.
TextChatService is really annoying to use because it basically has no backend. There is ShouldDeliverCallback
that is server side only, but other methods and events like OnIncomingMessage
, SendAsync
, MessageReceived
and DisplaySystemMessage
are client side only. There are a lot of instances where DisplaySystemMessage
would be used on the server, but it canât. SendAsync
as well, mainly for custom chat systems. If you want the server to process a message before it is sent to the chat filter, it has to do
client â server â client â server (SendAsync called, has to be filtered on the server I assume) â client
This is what I had to do for my port of LegacyChat to TextChatService
: /
I understand the api is not built for these to be available on the server, doesnât make it less annoying though
How does one make a custom chat command system using TextChatService? (For either porting old chat command scripts, or for more complex handling of chat commands)
The current only good solution is to use OnIncomingMessage
or SendingMessage
on the client (Because Player.Chatted
doesnât fire for the local player, but fires for non local players client side, and fires fine on the server side. Unsure if I should file a bug report for this? Itâs unclear is Player.Chatted is deprecated-ish?), and then either use a remote event, or use Player.Chatted
for server side commands
There is also the issue of filtered TextChatMessage objects not providing an unfiltered version of the message, which is annoying for chat commands, although not relevant to the solution above
And then, the callbacks⌠They are callbacks, so only 1 function can be bound to them. So if a custom chat system uses a callback (either ShouldDeliverChatCallback
or OnIncomingMessage
) for various reasons, then developers using this custom chat cannot use these callbacks without breaking the custom chat
end of rant I guess
Why wouldnât I want this on the server? .Chatted
can be manipulated by exploits preventing me from obtaining the true message on the server. Imagine I want to create a mainly text-oriented game, where players can do some actions through typing certain words in the chat. If an exploiter can manipulate this, then it will cause me all sorts of security problems. It makes our lives easier, and expands the capabilities of the TextChatService.
Currently, you have to do some annoying things with ShouldDeliverCallback to only process a message once. ShouldDeliverCallback is useful for its specific purpose, but its completely not idiomatic (requiring use of a cache of message IDs already processed) if I need to process a message once and only once, not even for delivery purposes.
Since it can only be defined once, if I need multiple pieces of code that want to process a message only once, I have to make some sort of system to run a bunch of callbacks every time from different places in my codebase. The amount of manual effort here is really annoying compared to just having one event that I can connect to from anywhere, similar to .Chatted
.
For example, a chat logging system. This can currently be implemented with Player.Chatted
, but what if I want to also log what channel they sent the message in, or the recipient to whom they are direct chatting? All of this is impossible without actually having the TextChatMessage and its metadata/properties along with it.
This would be wonderful. The performance overhead in terms of UI wouldnât be an issue for me at least - we use a custom UI for the intercom system I mentioned.
Even better would be being able to configure this per channel, but if its global, I figure I can process messages over a limit out by limiting them on the client based on channel and also having a server limiter in ShouldDeliverCallback
- so either one would be a huge improvement. 200 characters is simply not enough for a lot of purposes.
I believe a new rendering system could be implemented, like how platforms such as Twitter render their post components, if a user scrolls down, all messages that cannot be seen above will stop rendering. This could improve performance, though I donât know if engineering team will consider this.
About Player.Chatted
not firing on the client (for the local player), I hoped that LegacyChat running in the background would prevent my command system from breaking, but nah, it broke
My game is basically dead so I donât really care, but I expect this to be a major issue for Blockate (which hasnât been migrated yet), and probably some other games as well
are we going to get the option for cross-server messaging (among players)?
this forced migration impacts a wide variety of experiences across the platform. not having this option would be devastating
Why does it filter so much?
Whyy?? Iâm going insane!
[ GRID FIXED!!!] Rebuild [BETA
] - Roblox
If with the current message limit, the chat UI is already struggling to get good performance with a low footprint without constantly spiking to ~15ms at peak times and ~5ms on average. Imagine how will it work with a lower cap. Even if such system was implemented, which I highly doubt that Roblox would do, I would imagine it would show messages very slowly or have some problems of that sort. I just feel that would be the case, knowing Roblox, unless proven otherwise.
They have claimed to have released many such updates to improve the performance of the various TextChatService components not limited to the UI, however, almost none of them had a huge impact really. I donât even know when will the performance problems in TextChatService all be gone. I have been testing the same games and checking the Microprofiler and I have always had consistent results on them, nothing changed. One thing I have noticed is that, the huge spikes mostly only happen when the chat UI is open.
Honestly from my short experience using it seems easier than ever to break the chat system and have players say whatever they want. Thereâs easily findable tutorials on YouTube which I wont link to that people are showing how to break it
but with how complicated it is to work with I think youâre more likely to end up breaking it by accident. Especially intermediate level scripters looking to get their hands dirty. A lot of the documentation is outright unclear. It says the Text property of TextChatMessage is already filtered but thatâs really only after itâs processed. There arenât examples in the documentation showing how these are used. The old method you could just put it through TextService and there you go itâs filtered.
The other thing Iâve noticed is checking for the status of a text through SendAsync doesnât work that well. It will still say Sending long after itâs already been sent.
As some people already said, the new TextChatService lacks some fundamental features that the old chat system has, like the animated gradient, which the new one you canât really do it. Also the performance issues with it, and much more that other users have reported. IMO you should first fix the fundamental issues of the roblox developers before demanding a migration.
Iâll ask here because itâs an active thread
How do I stop messages from a certain TextChannel from appearing in the chat window/bubble chat?
My use case is that I implemented a custom trade chat between two players where the chat messages appear in the trading menu. That all works fine but I donât want the messages from the TextChannel that I created to appear in the chat window/bubble because itâs already displayed in the custom chat window. I couldnât figure out how to do this.
I tried to give it an honest shot, but not only does it entirely circumvent all the code i already have for it, it also doesnt let me easily do stuff like proximity text-chat, crew based text-chat (because it would flood the text channels way too much), and every chat message is visible for everyone. also text-based commands are dysfunctional as far as i can tell.
Im not going to use this.
The simplest reason being, i dont like being locked out of controlling client text (i.e., extra filtering)
The other reason is simply that i dont need it, i have a perfectly functioning chat system which i have full control over, and youâve taken that one thing away from developers as well now.
Iâve switched to GetNonChatStringForBroadcastAsync until we get custom chat capability without all the bloat back
Also as a small foot note, i hope you all are thoroughly ashamed of whatever this change you forced upon everyone has done to your profit margins. Then again, the chat isnt being used in the âpopularâ games anyways, so who cares right?
The new chat doesnât seem to allow for scaling. With the older chat I was able to actually size up the chat, but now many messages are cut short and put on a next line.
Why isnât there a way to resize the chat? The width slider suggests it can be made bigger, but it caps out early.
*additionally you can not change the scale of the bubble chat tail, or resize the bubble chat image itself