It’s amazing! It will work better on games that have a lot of models and details and will ensure the player a optimized experience.
Inherently, as a concept, how does this happen? Should it not in theory be the lightest? You create a button in the Topbar which opens up the chat window, you type something in the chatbox, and press enter. It queries the filter text endpoint, then checks with each player in the server to see if they should see the message, and then it’s displayed on their screen. Alternatively, after the filter text endpoint is queried, it’s sent to each player, but it checks to see if the message should be displayed before displaying it??
Shouldn’t the majority of this logic be on the server rather than on the client? Even if it is all on the client I’m not too sure what’s going on that somehow manages to make it the most complicated CoreGui, even with chat bubbles and voice bubbles..
Additionally, when compared to the 2021E client, the modern 2025M client uses almost 1000 more megabytes of RAM in the same exact physical environment. Will there be a thorough investigation into why this is the case?
Nice update! Unrelated but, theoretically, would /c system be added back for compatibility reasons?
People in my game and several games find it hard to do things without /c system.
You can implement your own version of /c system, I did that with my game since players used it to talk only using the over head text, what you need to do is create a command on TextChatService to make the server aware the command is being executed.
When the command is executed, on the server side it sets an attribute to the player, to make clients aware that player is in the “system” channel (this is actually fake, there’s no need to create a channel for this).
Then, on the client, using TextChatService.OnIncomingMessage, I see if the player sending the message has that attribute, then re-route the text so it can still apear over the player’s head (filtered, of course, make sure to check for this) and make it return a “TextChatMessageProperties” instance with the Text property set to " ", this essentially makes it not appear on the chat list, the text is still received, only the client first text received is not the filtered one, all other players messages are filtered so make sure to check for the message.Status property.
How can such a simple UI be so unoptimized? Like it’s just a chat window. I had already made a custom chat before, and none of these were issues. Same for the topbar; They are just static buttons that can open some UI Why is it so complicated?
Someone made an open-sourced version of this and so much more performant…
Anything the community makes is automatically more performant than core scripts at this point.
Core scripts have access to stuff us developers don’t have, yet it has worse performance. I script quite a bit and have noticed the script editor has gotten more and more bugs in the past few months. It feels like everything is getting worse in performance. I hope they fix everything soon or else the whole community might make a plugin for every window just to get optimization lol.
Edit: And yeah, making custom chat would probably be best. Although you have to deal with blocked users and all that.
I thought TextChatService was the most performant way—because its built-in.
Glad to see metrics which now represent that.
Thank you for fixing performance problems. The text chat issue spikes were annoying; hopefully the problems can be reduced almost entirely because you wouldn’t really expect chat UI to be what’s causing frame time spikes in your games.
This update is very welcome, but I think it is a big problem that only “######” can still be sent.
This is the reason I’m so against both Roblox and developers using React-Lua. It just eats memory due to the insane number of tables with cyclic instance references and multi-nested metatables you’re forced into using. The GC stands no chance.
As @Visuile has pointed out, there’s been an almost 7.5x increase in memory between 2021 to today. That’s too close to the timeline of Roblox reimplementing everything in React-Lua to be a coincidence.
Look, this may seem like a bad-faith argument, and I understand the benefits that React-Lua promises and (sometimes) delivers like being easy to write correct UI code. But the cost to that is it will be harder to write performant (as in time, memory, throughput and latency) code, and for something that runs basically every frame in every game, that just doesn’t sound like the right tradeoff.
Reactive code does not need React. React is like a plague and it’s so annoying that it’s spreading out of webdev. It’s already annoying there.
What exactly goes on in the background that makes this “the most complicated CoreGui”?
Correct me if I am wrong, but I still see a vast majority of games in the old chat. Not a skin of it, literally the old chat version.
Valid concerns, and with how LegacyChatService is seemingly still fully functional (albeit accessing it now might be harder if it’s even possible at all), it’s starting to feel like fearmongering now
We can agree that out of all CoreGui, one will have more requirements than all others and that in itself is not a bad thing. This is an expected result due to every CoreGui attempting to accomplish different needs and goals.
Now I may be biased as a good portion of my CoreGui time is spent on chat, however it is attempting to accomplish a bit. The ChatWindow, Bubble Chat, and some voice ui are all handled by this surface. It is also doing this while offering developers a public facing API to customize the look and behavior which is not something that most of CoreGui’s offer at this time.
I hope this isn’t misinterpreted that chat is needlessly complex, because I would disagree with that statement.
We have been rolling out an automigration path in batches. Depending on when you last checked, some of these experiences may have changed.
Yet not enough. ExpChat does offer a level of customisation that’s far greater than what other CoreGui does, but most of this customisation is only at an appearance level. Behaviour-wise, I believe some of these replies have already expressed their concerns.
No offense to your work, I greatly appreciate what you have been doing for ExpChat, but there really are some things that we can only achieve with custom chat systems. TextChatService should also be more friendly with developers implementing their very own interface. I remember seeing an option to report a specific chat message that I just cannot find in the documentation as an available API, perhaps we can have that. If we do already have this, please point it out for me.
I believe there is a front-page game using a forked version of the Legacy chat. Being a game in the Charts, I find it hard the game has not yet taken action over the course of these months. I am not going to say anything because I cannot really verify what is being done, nor do I want to be a snitch.
Recently, I also noticed that everytime I open the chat box, in just a milliseconds, i saw multiple frame showing at the that speed, some colored white some huge UI collapsing to each other and some is long small line. I feel like its messed up. And feels slow. Until finally this update was implement.
Is this a summary of changes over the past 3 months or have additional changes been pushed along with this post?
This is a summary of the changes we’ve released over the past 3 months and their impact. We ship performance fixes pretty consistently but don’t make a post for every one
Yeah, I agree. As a matter of fact, the main reason that I always post results by microprofiling on it on servers with a lot of players is because it’s one of the games that suffer the most from performance issues tracing back to TextChatService and/or its related UI components. Another game that suffers a lot from such issues is Multi-Crew Tank Combat 4. The spikes appear the most on games with a lot of players, with a lot of chatting going on, and with an intensive performance heavy nature.
I always thought that the maximum frame rate metric was the one mainly being tracked or at least the performance improvements were based on combating peak frame spikes, didn’t know the improvements were related to reducing the average frame time spent. Regardless, I’ve noticed improvements on both cases myself. ExperienceChatMain used to peak spike at ~15ms and was using ~5ms frame time on average, now it appears to peak spike at ~5ms and use ~1ms or so in average times. This is of course on my laptop and of course different devices with different performance backgrounds have different results. I think it’s a little more severe on my low-end Android Samsung Galaxy M12 phone.
Looking forward for further improvements that would completely eliminate random peak spikes, the average frame time being used, and also on minimal resource usage by disabled components namely Bubble Chat. Hopefully the performance and resource usage would at the end be comparable to that of the Legacy Chat System or better. I also want to emphasize on giving attention to memory usage too. This is significant and not brought out as much.
I have a recommendation though, you could learn from Microsoft and stop using React-Luau and indirectly Javascript because React which is what React-Luau is based on is scripted on that programming language. Both got terrible performances in what they were made for. More info here. It would be better to spend time migrating away from them at this point.
I’ve noticed that for automatically migrated games, the Legacy Chat System still appears on the dropdown menu list of ChatVersion on Studio’s properties. Is there a reason for that or is it just an oversight? Also, I am concerned about the performance impact of running the Legacy Chat System alongside TextChatService on automatically migrated games. I don’t find a reason for that, at least for games that uses the vanilla unforked version of the Legacy Chat System purely with no modifications or additions. I know this is happening because whenever I join any of these games, the Legacy Chat System UI flash or appear for a few seconds before the TextChatService UI appears over it. Is there a way to prevent this by the way?




