We shouldn’t but we’re forced to. ExperienceChatMain constantly shows up on the Microprofiler as the reason behind the huge lag spikes that could occur in experiences. It’s the number 1 reason for the huge lag spikes and fps drops that I get in experiences personally. I have no idea why sending text messages requires huge amount of resources, or why would a chat system causes huge lag spikes, or why would it still take resources and actually take huge amount of resources when disabled. All of these questions can only be answered by Roblox staff.
To be fair, ExperienceChatMain isn’t the only Corescript that suffers from performance issues, most Corescripts do. They usually all use more resources than developer scripts. It’s kind of hypocrite to encourage developers to do their part on optimization when Roblox doesn’t at all.
I dont know man… I would agree with you by not carrying what UI does to performance compared to physics or rendering. Except all of these new interfaces and ui’s crammed onto us have been nothing but a direct downgrade (performance and customizability wise).
The entire chat system stutters when trying to do ANYTHING. Opening the chat, starting to write, adding/removing characters, ANYTHING!!!
The micro profiler screenshot is my 14700k sending one letter using the chat system btw.
Okay, what is it then? What “code built on top”? And how is that code not related to the TextChatService? The GUI itself is slow, the functionality of sending messages is slow, everything about it is slow.
Magically if i switch to the legacy version, all of the performance issues vanish! I’m guessing that the old chat system doesn’t use the magic new “code built on top” but still seems to do the job just fine, no?
I am currently looking for a way to wait for the chat to be fully loaded, so messages can be sent.
Apparently there is no way to do this except using task.wait() ? The legacy system seems to not have this problem.
I hope we get something like TextChatService:IsLoaded() soon enough (As well as everything else that forces people to use the legacy system). task.wait() is risky and terrible.
this is awfully vague issue since there’s nothing that gives away the reason why it even causes this absurd lag spike
Ive allocated studio 4 cores to use and changed power plan to disable turbo clock. Feels like it really won’t be good for mobile users.
And it’s been like this for over a year already. Will something be done about it for once please? I tend to strive for optimizations a lot.
Literally any interaction with TextChatService will need at least 1ms to compute that event.
This might ESPECIALLY bother people with 144+ Hz refresh rate, since lag spikes will be more noticeable for them.
I see you edited your message, nonetheless even if it’s the build in UI that is build in on top of TextChatService the cause of the performance issues, it could still be a reason to not migrate to it yet. Not all developers would want to make their own custom UIs just to mitigate this issue and even if they did, they actually wouldn’t be able to because the UI components still run in the background even when disabled. There’s probably no way to escape these performance issues for now as long as TextChatService is being used.
I do not feel any security with the future of Roblox if something as simple as the chat service is so badly optimised and all feedback on it is entirely being ignored or given completely bogus answers. I am extremely dissatisfied with this lack of service. Developers make Roblox run, if you continue pushing us away you only lower the bar for a rival service to become a more viable alternative to switch to. Why should we waste years of our time developing unique non-transferrable skills on Roblox if the platform is only going to get worse and ignore any feedback?
I find it extremely incompetent that such performance and functionality issues have entirely been ignored when an acceptable level of beta testing before release would’ve easily discovered it, let alone that hundreds of people reporting it over a period of years are also being ignored. I further find it grossly negligent that an incomplete and very poorly performing REPLACEMENT isn’t even designed to match the functionality of the system it is to replace, let alone the performance downgrade which is beyond the level acceptable for an upgrade.
I really find it sad how despite Roblox’s many gigantic benefits over other services (free multiplayer servers with no limitation compared to the top earners on the platform, zero first party tools that are gatekept? A pre-made social, avatar, and physics engine etc.) they continue to sell themselves short, I just hope they finally realise this and change their tune…
It took a lot of time for ChannelTabs to be released only for it to be released in a very buggy state… It’s astonishing how these critical bugs have been left unfixed for over 3 months. It’s really annoying how features almost always gets released with bugs and the bugs take forever to fix, and even when they do get fixed, new bugs just appear again.
The point is that it doesn’t justify the huge delays in releasing features or updates when they just almost always do with bugs. It feels like there’s barely any testing here. It would’ve been better if the issues would get fixed quickly but no, they don’t. The concept of releasing unfinished or buggy features to fix or improve them later is very stupid, because it almost always results in these fixes or improvements never coming or just coming late.
Personally I prefer the old roblox chat as it allows you to use /c system. With the new one you either have to priv chat someone or /team for command usage. But I guess it’s fine . . .
If I try contacting roblox support, they won’t do anything. I filled a DMCA removal request since someone copyied my group description, work and they we’re suppose to give group back but nothing. And roblox moderation didn’t do anything…
what do you mean? the only thing that’s there is the blue colors, that’s it. And that was only used on an active channel bar where it has that old Roblox colors.
You can use CoreGuiChatConnections to determine if chat visibility has changed. Make sure you fire the bindable for VisibilityStateChanged when handling events from SetVisible, ToggleVisibility and CoreGuiEnabled to avoid any visual bugs.