Update on Legacy Chat Deprecation and TextChatService Migration

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.

1 Like

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

2 Likes

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.

1 Like

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.

1 Like

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.

1 Like

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

1 Like

Why does it filter so much?

Whyy?? I’m going insane!
[:hammer_and_wrench: GRID FIXED!!!] Rebuild [BETA :tada:] - 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.

1 Like

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.

1 Like

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.

1 Like

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

1 Like