ah yeah the one that takes up more screen space than the first (semi-transparent bar thing) version
1 Like
Yes, in fact, you’ve just re-invented the TextChatService. That is exactly what the TextChatService is trying to do, provide a general API for chat (speakers talking to eachother in a set of channels) with a rich enough API surface that we can handle policy automatically.
4 Likes
Right now one of my experiences forks Roact bubble chat so we can support inlining images to chat as well as context-aware bubble highlighting (it’s actually just highlighting based on the current channel the message is sent to). Would we be allowed to continue to support that as long as we receive messages via TextChatService to render in bubbles or do we have to remove that and wait for Roblox to support inlining?
Relevant context:
That’s great! One difference, though: this proposed API wouldn’t be a forced Service that limits my capabilities and does not create a thread that hogs performance! It also allows me to create my own chat system with Lua that allows me to write my own channels and message sending system.
TextChatService is close to matching this definition. But not quite there.
TextChatService APIs are intentionally designed to be “low-level” and flexible to replicate these more particular usecases.
You should be able to emulate bot speakers using a combination of TextChannel:DisplaySystemMessage to output anything you want into the ChatWindow and likewise TextChatService:DisplayBubble to show a chat bubble anywhere you want as well.
I believe we are creating a luau resource in house that we will share soon that adds a nice interface on top of these methods specifically to replicate the “bot speaker” case
We’re writing some documentation to help clarify this – but for now I can say you’ll only need to use CanUserDirectChatAsync if you’re creating a chat feature similar to the built-in whisper command where a user can choose to directly chat with another user.
If most of your TextChannels are assumed to be public then you won’t need to gate the TextChannel with this API.
2 Likes
First, y’all remove user-to-user inbox messages, then Account PINS and now Legacy Chat. I swear if this, then I’ll find a way to bring back legacy chat in my games. I do not call them experiences, Games are better then “Experiences”.
Seriously, all legacy features have to be removed, and y’all MODERATE us for wanting to have the Legacy Chat in our game, This is SERIOUSLY Wrong.
2 Likes
I am actually really angry about this change, I do not accept it and let developers have the Legacy Chat stay on roblox.
3 Likes
What particular capabilities do you feel are missing?
A TextChannel just represents a set of candidate recipients for messages. You can use the channels for whatever purposes you want if you’re writing your own GUI as long as every sent message goes through one of them. A lot of different potential patterns can be implemented using them (team channels, public channels, 1-on-1 conversations, etc).
1 Like
Roblox making good changes challenge (Impossible Edition)
3 Likes
yep., and I am actually really angry about this. They keep removing features that we’ve needed. Like Account Pins. They gone cuz they need to REMOVE everything.
3 Likes
Couldn’t agree more.
If we’re speaking about removing things, A good step is removing the stupid thirty Chaaaaarrrr limit. It’s 2024 nobody is going to raid the forums 
.
1 Like
Why would I need to use another account with parent privileges? is it required for users who had PINS activated on their account? if yes, then I’m not doing that. PINS have been here for years and they helped me to keep my account safe, but now REMOVING Them makes me feel like that my account will be in more danger.
Removing them is not a good decision. There’s a post saying y’all should reconsider to let them stay on roblox.
3 Likes
I’m not sure if this is a great idea Roblox. Removing Legacy Chat (and custom UI) that has a lot more freedom and replacing that with Modern Chat aka TextChatService for experienced developers is wrong. It limits the amount of freedom experienced developers can have in their games.
2 Likes
Thank you, my game uses only 1 TextChannel which is public that means I’m safe.
1 Like
And I think I have TextChatService judging by the icons that I have in my game.
This post is not the place to get answers about that unrelated change.
I wasn’t involved in that particular decision but what I can tell you is that removing and changing things is nothing new: Right from day 1 Roblox has always been a platform that evolves rapidly and tries out lots of different approaches to things over time, not one that stands still and and rests on its laurels.
1 Like
well there hasn’t been an announcement post of removing it, so where should’ve i posted it in? in #development-discussion?
I know removing is nothing new, but this makes me disappointing about this when I just saw this email.
Yup, you should be able to continue using your custom chat bubbles. The announcement states that Roblox does not mind how messages are rendered (as long as its not violating any obvious rules), instead the concern is that the messages should be sent through TextChannel objects.
You can think of TextChannels as a RemoteEvent with a few extra features. You should be able to continue rendering your bubbles from a TextChatMessage object
3 Likes
I think I can gather up a small list from my old YouTube video where I demonstrated some features of my “old” chat system. I actually got inspired by TextChatService and used it a little inside that system in certain places.
It’s not about the “UI” really. It’s about the capabilities that being free gives me. Roblox Engineers can implement really useful features but alas nothing beats being able to write your own system freely. The possibilities that arise from being able to create your own implementation easily beat the possibilities of being forced to use a certain API.