Update on Legacy Chat Deprecation and TextChatService Migration

Yeah, some experiences still have it enabled, it may take some time to complete it idk

1 Like

If anyone has access to Feature Request, please request a GlobalTextChannel :pray:

6 Likes

Documentation is quite horrible, and I cannot find any way to migrate my chat systems to the new setup. This is definitely not a pleasant thing to deal with. The amount of work ahead of me to figure this out is absolutely atrocious.

1 Like

Hi @DieselElevatorsRBLX If you are on an unmodified version of Legacy Chat you should be able to switch the version of Chat you are using in TextChatService within Explorer → TextChatService → ChatVersion → TextChatService.

If you have a different configuration and need more help do reach out.

1 Like

We’ve started to automigrate experiences to TextChatService in batches. If you have custom chat features, we strongly recommend you manually update to TextChatService. You can do this before or after the migration.

Please read through our migration guide for tips on how to implement key chat features. We will also soon be launching Studio tooltips that will notify you if your experience is now using TextChatService at runtime.

12 Likes

I’ve noticed that some of my experiences got the Legacy Chat System migrated to TextChatService on the client, however within Studio, it still uses the Legacy Chat System and the property shows that too. I also am able to change the property to TextChatService and back to the Legacy Chat System again and it won’t lock the property for me. Similarly, creating a new experience allows you to select the Legacy Chat System on the property and use it on Studio, however it would instead use TextChatService on the client. This is very confusing. Please make the behavior consistent here between the client and studio.

So are yall trying to pull a 7zip here? After an experience was automatically migrated, I noticed how the developer of said experience was able to just turn it back to LegacyChatService, as TextChatService broke some scripts
In that case, why are yall even bothering with this then? This “constantly urge the user into using the new system while keeping the old system perfectly functional and easily switchable” type strategy worked with 7zip as it was actually useful software, and it was functionally more like donationware than any license based thing in particular, but it won’t work with the TextChatService as it’s got multiple flaws, and it still feels generally unfinished, almost as if yall worked on it once for a month and never again

So at runtime TextChatService is now running for migrated experiences. We didn’t want to force change the version within Studio since that could cause potential errors with your experience. We are looking into if we can do it safely, but for custom legacy chat versions we’d rather creators update the version on their own… We are working on removing legacy chat as an option for new experiences but it isn’t out yet.

1 Like

Can you add a RBX event or property for when the Chat does load in. At the moment my local scripts have to wait a second when player joins because I am unable to get the exact moment the chat is loaded. If you try displaying a message before it loads then the message will not appear and that’s just annoying.

Here is a example of a different developer having my similar issue: There should be an event for when the chat window has loaded (TextChatService)

TextChatService in its current state is not usable for our social deduction game. Exploiters can see what members are in what channels which reveals information that gives exploiters an advantage. The solution to this was a custom chat backend that selectively replicates chat information. The only solution is whisper channels between all players but this is not robust and whispers are likely subject to different filtering rules. Going to reintegrate TCS because the whisper channels is at the cost of UX but using TCS requires knowingly reintroducing a vulnerability.

4 Likes

Yeah we can definitely add it as a future update.

1 Like

Can you guys implement a Server-safe version of the .Chatted event for TextChatService?

I wonder what category or criteria of experiences got migrated. I still see many many games, mostly popular, some are very, some got around 300-500 players daily still having vanilla Legacy Chat on.

Also, for migrated experiences, is it possible to lock and force the TextChatService property to appear as TextChatService being the option. I’ve noticed that the migration is now also forced on Roblox Studio. Also for some reason, the Legacy Chat system UI appears for brief seconds then TextChatService UI appears instead. Does this mean that both chats run at the same time? This seems useless considering TextChatService is forced enabled and in a game that was using vanilla Legacy Chat System. This whole migration process seems unsmooth and messy for me.

@rbtia_rbx Sorry to bother you, but I’m curious how the auto-migration process works. If you have code running in a legacy chat service script (i.e. ChatServiceRunner, BubbleChat), would that code still run? Or will it just automatically switch everything to TextChatService?

Also could we know the time period for migration roughly, if you know?

Or if a game has game.ServerScriptService:WaitForChild('ChatServiceRunner') is it just cooked?

The 200 character limit is still a huge blocker for migration - we have a server-wide intercom system for players to use, and GetNonChatStringForBroadcastAsync is both too strict and technically incorrect, risking our game being moderated for using it, since the system is more akin to player messaging.

The alternative was GetChatForUserAsync, but that has now been deprecated on the client (which I didn’t notice in any of these deprecation threads - game broke overnight) and I’m not sure about the ramifications of doing a GetChatForUserAsync call on the server for every single player in the server. I also lose out on the vast benefits of just using TextChatService.

I can get past ShouldDeliverCallback being the only server-sided way to receive messages with all their metadata, such as the channel, which Player.Chatted cannot do (TextChatService: No method for the server to always receive chats) but the 200 character limit is still a complete blocker. Would love a way to change the character limit globally or on a per-channel basis.

1 Like

A lot of things related to TextChatService are still majorly lacking in customization and freedom compared to legacy chat. I’m surprised they’re forcing a migration without giving developers an actual viable alternative to legacy chat.

Hey, we discussed this, in the future we could offer 200 as a default limit and then developers could configure a higher limit. Though, this could come at a performance cost.

So Legacy Chat code will still exist in your experience but it won’t work since GetChatForUserAsync API is deprecated. Otherwise TextChatService will be running instead.

We recommend you manually migrate any configured functionality to TextChatService, your old scripts will not work in the new setup. Let me know if you have more questions.

1 Like

Yeah so legacy chat still exists within your code, but TextChatService will now show up as well. Feel free to manually update your version to TextChatService.

1 Like