Because you’re saying has which based on current information is not true. The last major exploit with legacy chat was patched more than 2 years ago and no exploits have been uncovered or at least publicized since.
I don’t mean to accuse you of lying, and I am certainly not trying to attack you, but I do think you are misinformed because I promise you if there were actively “tons of security issues” then we would have a significantly different post here, both from Roblox and a different reaction from the community.
This is just me speculating but… I’m assuming that Roblox doesn’t use legacy chat for automatic AI moderation anymore due to the issues of games using it maliciously to get users banned from the platform. The change of requiring the new TextChatService seems to have worked around those issues and resolved them.
I always wanted to migrate to TextChatService, but the thing that has turned me off from it was the fact i cannot give it a specific chat window position and im limited to only corners.
The automatic AI moderation exploit using text chat to make players say bad things was the exploit I was referring to and it’s been fixed for 2 years now, and it didn’t require the use of legacy chat, it just happened to use it.
Though, it is certainly possible that Roblox would’ve disabled AI moderation there regardless just to be safe, but I wouldn’t be so sure that they did it immediately afterwards given the fact that I have seen people banned by AI moderation on legacy chat games less than a year ago.
Edit since someone is likely to mention it: The second “Crosswoods” incident from a few months ago did not use chat as it’s method to ban people.
Edit 2: Turns out I was incorrect on that front - however, it seems like regardless, Roblox still hasn’t disabled AI moderation and it still works on both legacy and modern chat. I was confused because there are multiple methods which exploiters have used to force ban accounts, even tricking Roblox into thinking that you’ve started a payment dispute. But as far as I can see there are no current exploits which can ban you for chatting on legacy chat that can’t ban you on TextChatService. Regardless, this should just be fixed anyways instead of rushing a change like forced migration, and plus, it’s not even the reason Roblox lists in their post.
If there is seemingly nothing stopping us from using our own custom UIs with TextChatService; then what is stopping Roblox from re-creating the legacy chat system using the APIs? If TextChatService is flexible enough for all desired use-cases then it should certainly be possible to port it over. There would still be issues with forked versions but it would still ease the pain for at least a few developers.
Why isn’t this just encouraging us to move over to TextChatService then? If these are all the reasons wfor why you want to make this change, it doesn’t explain why developers aren’t allowed to make their own system if they are willing to make changes with ever-evolving policy changes. There are many use-cases not covered by TextChatService and developers who are willing to comply with an ever-evolving world of policy updates should be allowed to do that.
Why are announcements from admin commands considered a chat message while “Writing a post on a bulletin board” isn’t? Both are very same in purpose?
This is the major thing I wanted to flag, because of this cross-server messaging systems are no longer allowed since TextChatService can’t support cross-server communication given it’s current architecture.
This would mean global chat systems aren’t allowed since they physically can’t implement the TextChatService APIs.
A few notes about TextChatService and why it isn’t suitable to migrate over to:
Default UI isn’t customisable and it’s an absolute pain to make a customisable version of the UI.
No cross-server messaging support; like seriously this is a deal-breaker. We can no longer allow players to send messages to players outside the current server if this policy goes into effect.
No obvious benefits to developers over current APIs; custom UIs are still allowed so why couldn’t we just get more robust APIs for checking if a message can be sent given the context?
why make this change when so many features are just missing from textchatservice
you cant customize it easily (in regards to behavior, not appearance) but roblox doesnt want us to make our own chat systems either? (not directly said but heavily implied by them making this sudden change that you MUST comply with)
there is no serverside way to modify (like the old command and “filter” functions from legacy chat) sent messages as far as i’m aware (what ever happened to “never trust the client”?)
more fun stuff! auto complete for textchatservice isnt able to be controlled properly (what if i dont want to use emojis but i do want commands?) and also not a good way to let certain people autofill commands (no one wants their secret admin commands leaked for obvious reasons)
this is all to say:
PLEASE FIX TEXTCHATSERVICE
(by the way how are announcements considered chat more than a roleplay name??? it feels like the same concept no? and even worse how am i supposed to migrate to an api you guys havent even made yet, kind of ridiculous honestly…)
wow i really wasted my time writing this knowing full well roblox doesnt care about what developers think… lol >_>
One of my games has a Cross-Server Chat implementation using MessagingService APIs. It does do the chat filtering and all that. That’s supported by Roblox currently. My experience needs to do this as the experience is SINGLE PLAYER. How would I use TextChatService to communicate across game instances?
Firstly, I’m going to be honest. This post is horrifically worded, phrased, and presented. I understand the motivation and underlying change here, and it honestly isn’t relevant to 99% of Roblox developers. So let’s go over the disasters:
The wording of moderating a game instead of saying you are going to take down the game. This has shown to make people believe that their accounts will be terminated. not the case.
Lack of clarification that this is about the internal API, AND THAT FRONTEND DOES NOT MATTER HERE. There’s nothing stopping developers from using the new TextChatService APIs with custom chat UIs. I will make a project myself which will restore the old UI while still being adherent to the new ToS, and I will open source it (I have an old 2015 styled Roblox game that I’d like to maintain the old chat UI for).
The title is worded “Removing support for legacy chat and custom chat systems”. This is not worded well. It is ambiguous, because if you do not read/understand the post, you might not understand that this is about disallowing Luau-based chat systems vs. ones going through Roblox APIs.
This is a large change targeted at developers, however the title’s wording and the initial phrasing make it seem targeted towards everyone. In reality, this change pretty much won’t affect you (besides the UI, if you don’t bother replacing it) unless you’re forking the old legacy chat.
Many people think that TextChatService is about the frontend. Many people don’t understand what TextChatService is truly about. This is never clarified.
It is also not directly pointed out enough that there’s an option to use the old UI
“Legacy Chat” is not clarified to be referring to the old version of TextChatService.
It is REALLY not emphasized enough that this only matters if you’re using a custom legacy chat fork.
The impact that this has is overblown to massive proportions. However, onto the community side of things:
You guys are illiterate
Please have basic media literacy
At the very least, ask some stupid questions and get some replies and clarifications.
TextChatService does have a new frontend UI. However you have no obligation to use the UI, and there is absolutely no requirement that you use the UI. TextChatService is primarily a backend service which allows for better moderation and systems to be built. The TextChatService API has more features, and likely better performance.
There is a large difference between TextChatService API and the TextChatService UI. Frontend vs backend, people.
Please do keep in mind that there are still very valid concerns, more specifically are cross-server messaging and modifying message in-transit (for example, for custom filtering)
In my example, expecting regular clan leaders to manage and create this on their own isn’t realistic, especially since the default UI is pretty rigid right now. Unless it gets a major overhaul (hopefully a good one this time), most of us are going to be stuck with these limitations.
I appreciate Roblox’s efforts to evolve, but I’m concerned that this decision could significantly impact most, if not all, older games that haven’t been updated. The scheduled removal of LegacyChatService by April 30, 2025, leaves many classic experiences at risk unless they are automatically transitioned to the new TextChatService, which I doubt will happen and may make matters worse.
What plans are in place to address performance issues and enhance the TextChatService API with better customization options? I rely on many custom chat systems for essential features, and I know I’m not alone. These systems, as well as older games, depend heavily on the LegacyChatService API.
Additionally, the proposed moderation of experiences—including older games—raises serious concerns for me about lost media becoming an even bigger issue. If Roblox is moving forward with TextChatService, I urge you to leave experiences that haven’t been edited or touched for a significant time untouched and accessible. It’s essential to preserve the history and creativity of the Roblox community while ensuring a smooth transition for developers.
So, am I to understand that the primary motivation behind this update is the parental controls system?
While I fully support compliance and safety, it shouldn’t be solely the responsibility of developers to update classic games that have remained untouched for years. Roblox should take the initiative to enhance its content moderation systems or develop better methods to monitor chats, images, and voice interactions.
What about games that aren’t closely targeted toward a younger audience? Why are they subjected to moderation standards designed primarily for children? This approach can stifle creativity and the unique identities of games that cater to a different audience. I feel Roblox is so focused on being child-centric that it’s causing issues for games that are 18+. (and not even related to children)
I’m frustrated that developers are being forced to migrate to a new chat service without receiving the features we’ve been asking for. There are many ways Roblox could better utilize LegacyTextChat instead of compelling developers to abandon it and rewrite their entire moderation systems.
Moderating your developers, the very people who keep your platform active every day, for not complying with this new chat service is unreasonable.
Are you saying you want to remove the TONS of old media and games that exist in exchange for a better moderation system? Why not allow developers to enhance their existing systems instead of forcing them to rewrite everything?
I appreciate your patience in reading through this lengthy message. Thank you for taking the time!
That API doesn’t handle filtering and presumably we’d need an API to handle filtering on a user-user basis (given the mention of parental controls restrictions) even for cross-server messages.
ffrostfall, no need to be a mean about it. I wasn’t complaining about the new system, I just wanted to know how to go about using it to do my usecase. I had not even considered :DisplaySystemMessage() as a means of showing chats from other users, as this is clearly not the intended usecase for that. I had seen some mention of them looking into cross-server chat, so I thought there might be a better approach. But yeah, I think that will work okay.
Okay, I see it *kind of. There is no direct specification for cross-server messaging, however you can already get 90% of the way there by CanUserChatAsync and GetNonChatStringForBroadcastAsync
*because this is very blurry waters, and there’s a difference between cross-server broadcasts and cross-server chats. You can ask Roblox to clarify on that but 90% of “realtime chat systems” don’t scale off MessagingService anyways due to experience limits, and broadcasts are often the wider use case.
The API does actually handle filtering, and the issue I see with the API is that there is no way to have a TextSource with a UserId not in the server.
As I clarified in another post, it is fine if this is integrated behind existing TextChatService APIs and it is not a “conversation”. Roblox differentiates this in the post:
If possible, you should open a feature requets for this API to allow UserIds not in the current server, but rather in the experience. I think it’s fair criticism, as I honestly did not originally notice you couldn’t add users from other servers.
First of all - most people aren’t complaining about the UI itself, read the replies.
Second of all:
Not unless you implement it manually.
Third of all:
No. It is referring to the “Chat” service. Not an old version of TextChatService, that doesn’t make any sense.
Then of course, we have this.
This right here is the biggest problem, everything else can be hand waved except for this. Because no, it does not. If you read some of the replies you would see a lot of complaints primarily about the performance, because it really is that bad.
TextChatService has a performance penalty so severe that it’s virtually unusable in certain games because it can have as much as a 15ms penalty on it’s heartbeat function, and it does not take a whole lot for this massive time penalty to manifest.
Not only that, but TextChatService misses the bar on a lot of very important features that the normal chat has, I would go over these but they are too innumerable and several other people have already pointed out a few that are missing in this thread. Do note that a custom solution is not a valid response to the lack of features when a previous iteration of the system had those features built in.
All of Roblox’s CoreScripts are written entirely in Lua, save for the C++ hooks (which typically aren’t designed specifically for CoreScripts). That includes the handling of TextChatService (
Script_CoreScripts/ExperienceChatMain). But it’s actually more fundamental than that because there’s still a performance cost to TextChatService over legacy chat even if the respective scripts are DISABLED.
This is a bug that has existed for more than a year and Roblox still has not fixed and it results in the performance penalty being significantly magnified on consoles (Since they have a weaker CPU, and even though they don’t have chat, the TextChatService still is loaded). If it were fixed, and a few of the loose ends rounded out, literally nobody would care about this migration, but the system is literally underbaked and flat out not ready to supersede legacy chat.
what do you think i meant by old version of TextChatService?
Ok so actually I kind of messed up with this one and did not validate when it was mentioned to me. However you still can implement it yourself and no one is stopping you.
CPU flamegraph w/ no scripts in studio (so it’s optimize1)
we have much bigger corescript issues than ExperienceChatMain eating up a grand total of like, 16% of the 70ms that CoreScripts eat up after multiple seconds
EDIT: It appears that there are no per-frame jobs relating to TextChatService on the server. (Real, production game using TextChatService)
and yes, these are kind of annoying, but you are never going to be so tight on optimization that these are posing a problem. no one is playing your game on a 300hz monitor, and you can definitely reach acceptable FPS on mobile without that being a concern (I did it)
leaked for obvious reasons)
