It appears they have updated the post to confirm that they will attempt to auto-migrate as many games as possible, or disable chat if auto-migrating doesn’t work in a particular game, and if they can’t disable the chat either, then instead of taking down a game it’ll just be set to private.
I think they’re saying they’ll only consider moderation action if creators continue to deliberately use chat bypasses.
If I’m not mistaken,
if you are not using custom chat and have made zero chat modifications, you should not be affected by the auto-migration.
now how do I remove chat altogether?
if the legacy chat is going to be removed then I can’t remove chat anymore since this new chat system doesn’t seem to allow us to remove it
You could create a new UI that supports rich text, hooking onto the TextChatService methods and just parsing the rich text should work. You then can render the message using your own code. Regarding moderation, you could pass the rich text data into metadata as a series of pointers where the rich text tags get injected at render time. User facing wise, you could add Italic, Bold and Color editing options to the text field (Reminder you completely control the UI: you just need to use TextChatService methods instead of RemoteEvents)
For the automatic migration, will be there any attempt at preserving any level of visual or functionality from the old legacy chat, especially the instance structure of it? There are definitely games that rely on legacy chat and/or legacy chat bubbles to be the way that they are. This also seems more of a back-end update than a front-end one.
Do you know by any chance the length limit of metadata string? Cuz with some amount of formattings applied, I resulted in 2k+ symboled metadata, which I assume got dropped.
Our game has a global cross-server chat sent over MessagingService, but TextChatService doesn’t seem capable of supporting it.
Limitations I encountered:
Properly filtered message contents can’t be obtained, so its not feasible to transport the message properly (this is the main showstopper, considering :GetChatForUserAsync() shouldn’t be used and :GetNonChatStringForBroadcastAsync seems pretty obviously off the table)
Can’t author messages that originate from other users.
Use cases
Games which simply have global chats that are shared throughout all servers & places in the experience
Games which use private servers & sub places for different isolated locations (e.g. a lobby place, a main place, and a test place, which might want their own shared chats isolated to them, or might want none at all)
Games which use private servers & sub-places to create coupled multi-server environments (e.g. two private servers, Earth and Moon are coupled together, and the developer wants to share chat between the two private servers but not between other Earth & Moon pairs)
Dedicated solutions & considerations
Possible dedicated solutions
There are two paths that seemed sensible to me for how this could potentially be directly supported by the new chat system as a sort of out of the box feature, each with different pros and cons. I am sort of imagining what a feature like this could look like at scale here, and not really focusing just on my use case alone, so it’s worth mentioning that this is all way outside of the scope of how I actually use global chat in practice.
Wishlist
Automated filtering should work out of the box
Automated translation should work out of the box
ShouldDeliverCallback or a cross-server equivalent should exist for the sending server & receiving server
Interactivity with usernames, whispering/messaging, etc, would ideally be supported out of the box (I can imagine with in-game PMs being on the roadmap it’s likely that if the user is in another server it could just fall back to this for whispers and stuff)
Option 1 (Managed by developers)
Roblox provides a way for developers to generate user messages that Roblox handles as normal, which definitely provides the most flexibility.
A way to create TextSources for users not in the server is added (e.g. either by default or via a new method designed explicitly for cross-server purposes)
A method is added to emit messages for TextSources (e.g. a method on TextChannel similar to :SendAsync, or a method on TextSource designed for emitting messages from the TextSource)
It is up to developers to clean up TextSources
Considerations
This is probably relatively cheap to implement, and it would be easy for developers to use.
The ability to create TextSources for users not in a game would almost certainly open up undesirable options for abuse, as messages sent in this way would sort be expected to be indistinguishable from regular players in a way that (even formatted/colored) system messages might not be (assuming they have special functionalities like clicking on the names of users to message them)
Developers would be accepting MessagingService budgets.
Roblox would maintain the ability to turn off the behaviour entirely by having TextSources start returning nil, false again.
Option 2 (Managed by Roblox)
Roblox adds a way to make a TextChannel shared across all servers out of the box.
Could simply be a boolean property on the TextChannel, and some kind of unique identifier to represent the channel.
Roblox can keep track of the users in a text channel across all servers and potentially invoke ShouldDeliverCallback in the sending and receiving servers to allow developers to cull messages that don’t need to be delivered across servers (it’d likely be beneficial in this case for developers to be able to identify both that a TextSource is originating from another server, and what server the player is in)
Roblox could also implement chat persistence across teleports for these channels if they wanted to do so which would lead to a more cohesive experience
Considerations
Would probably need its own budgets & considerations for how to reduce and optimize bandwidth when sending many messages to many servers, which would pose additional complexity and cost
It is worth nothing that a shared channel seems almost 1:1 analogous to a MessagingService topic to me down to subscriptions/publishing
TextSources would still need to be created, but, the potential problems above would be avoided by restricting this capability to the engine.
Less control for developers, but doesn’t add any new surface area for abuse that has to be considered (and still leaves options for the above)
Would allow for more fine-grained UI support (e.g. clicking users names to message them in the in-app PMs listed on the roadmap)
c.c. @Photoguy82, I think you’re the right person to mention
After testing, I found that metadata limit is 200 symbols. Enough to fit 15 chat tags which contain color data. Or 27 fonts, or 48 bold/italic/underline/striketrough formattings. cCM>♫♫↔ F§☼ cCMEJ♫→☼ F§► cCMMJ♫→► F§◄ cC♫↔J♫↑◄ F§↕ cC♫↔MM↓↕ F§‼ cC♫◄MM↑‼ F§¶ cC->◄M→¶ F§§ - I don’t think that there’s any more compact way to store this (1 symbol - type of formatting, 2 symbol - type of stored format - C = RGB, H = HEX (not unified due to some complexities of re-applying), 3-6 - HEX code)
You will update the documentation for the new chat service, and you will also provide an equivalent for all of the functionality that the legacy chat service offered. Failure to comply with this requirement will result in us refusing to migrate.
Same opinion here. Roblox needs to actually fix and update features before getting rid of the better version prior. I personally can’t use TextChat because for me it has alot of bugs and alot of ui issues related to my client.
This effect is not possible with rich text as it uses ui gradients, as well as the custom images used for the chats. The colors of the chats also change in real time. I even went as far as to make them fade out when the chat window fades out. Right not that is one feature I don’t think is even possible to mess with, I wanted to make a custom chat window with the new system and something as simple as making my custom window fade out with chat is impossible from what I saw. Not to mention I couldn’t even move the chat window away from the side too account for the custom window borders. I’m not sure if the new chat can do this, but the old chat I remember you could move it anywhere on screen. The new chat has a few options but that obviously isn’t enough control if you want to get fancy with the chat window.
Now don’t get me wrong the new chat back end is probably alot better, but certain features of the old chat have not been properly ported over. Something as small as checking how faded out the chat window is sounds like a dumb feature but its little things like this that make the new chat system less in our hands (developers of games) and more just a box we have no say over.
EDIT: actually support for gradients was added, but animating them and attaching extra ui elements (such as animated image labels and what not) are still something I don’t see support for.
You can do all of that using TextChatService. If you want very specific features such as adding images to your chats, you just need to make your own UI.
Ok, how do I make the my ui fade out with the chat, and offset it about 8-12 pixels from the left of the screen. These are 2 things that I actually need for 1 of my projects.
TextChatService is under core gui and cant be modified with scripts???
Edit to add on to this: If TextChatService was not under core gui then none of these issues would exist, as a dev could simply modify any part of the chat ui without any limitations. And that’s how it should be in my opinion. Its why TextChatService can never truly replace legacy chat, as legacy chat has literally 0 restraints while TextChatService is locked away from developers.
You need to reread this post as well as looking into the TextChatService API. You don’t understand that TextChatService is not just the default GUI. Make your own GUIs if you need your very specific features.
