That’s an off-topic post, and I think that may even get your reply removed. Also yes, development discussion would be a good place to post it if it was formatted in a better way.
Yes, it’s not as free as literally no restrictions, but I think you’re underestimating what’s possible. Just for example, you can implement threaded messaging using TextChatService by attaching target message ids in the metadata portion of the message.
Add the ability to know when the chatbox is visible/nonvisible, having to make some sketchy workaround to is isn’t exactly suitable. in the old chat system I was just able to use the chatbox directly to figure out if it was visible or not visible.
This. I had a lot of struggle with the state of the TextBox of the TextChatService, and without using a custom UI solution, it’s not possible to get the state of it.
I don’t think so. In fact, I’ve created a custom chat command system that automatically sizes and puts itself under the chat window. A lot of things are possible, yet I chose to advocate for freedom. Because in the long term, that will benefit me the most.
TextChatService and TextChannels are designed to be a very flexible when it comes to capabilities.
I’ve watched this video presuming its the one you’re referring to and all of the features seem to be matters of UI.
- images and profile avatars inline
- mentions
- command autocomplete
- channel sidebar
- system messages
- deleting and editing messages
- emoji shorthand and autocomplete
- resizable chat window
- text formatting tags
My impression is that you may be arguing that every option in the feature set above is not available out-of-the-box with the default TextChatService UI.
The good news is that you’re still free to implement all the features I can see in this video with TextChatService. This post is not prescribing that you must use the default UI that comes with TextChatService and you are still free to implement any UI treatment on top of TextChannels as you wish. Implementing your own UI will of course provide a lot of flexibility in how chat is shown.
Please be more specific in what freedoms you feel are being lost as a result of this announcement so we may either implement additions to the API surface or improve our documentation.
StarterGui:GetCore("ChatActive") still works as expected with TextChatService. You can use this to determine if the chat window is active.
You can use ChatInputBarConfiguration.IsFocused to determine if the default TextBox is currently in focus.
Yeah but the issue with that, is it isn’t exactly accurate to what I’m wanting. with the old chat system I was able to use actual chatbox and listen for its visibility to figure out if its actually visible or not. I could care less if that button is white or black, I want to know when the BOX is visible as I have a radio system in place and I adjust the placement when the chatbox is visible compared to when its not. I shouldn’t have to make this wonky workaround
StarterGui:SetCore("ChatActive", false)
Player:SetAttribute("chatBoxHidden2", true)
Player:SetAttribute("chatBoxHiddenConfirmed", true)
Player:SetAttribute("lastFocus", tick())
game:GetService("TextChatService"):FindFirstChild("ChatInputBarConfiguration"):GetPropertyChangedSignal("IsFocused"):Connect(function()
local ChatInputBarConfiguration = game:GetService("TextChatService"):FindFirstChild("ChatInputBarConfiguration")
if ChatInputBarConfiguration.IsFocused == false then
local start = tick()
Player:SetAttribute("lastFocus", start)
Player:SetAttribute("chatBoxHidden2", false)
Player:SetAttribute("chatBoxHiddenConfirmed", false)
repeat
task.wait()
until tick() - start > 4 or Player:GetAttribute("lastFocus") ~= start or ChatInputBarConfiguration.IsFocused
if Player:GetAttribute("lastFocus") ~= start then
Player:SetAttribute("chatBoxHiddenConfirmed", false)
return
elseif ChatInputBarConfiguration.IsFocused then
Player:SetAttribute("chatBoxHiddenConfirmed", false)
return
elseif tick() - start > 4 then
Player:SetAttribute("chatBoxHidden2", true)
Player:SetAttribute("chatBoxHiddenConfirmed", true)
end
else
Player:SetAttribute("chatBoxHidden2", false)
Player:SetAttribute("chatBoxHiddenConfirmed", false)
end
end)
local lastChatActive = StarterGui:GetCore("ChatActive")
local chatActivatedAt = nil
local check = nil
RunService.RenderStepped:Connect(function()
local chatActiveNow = StarterGui:GetCore("ChatActive")
if chatActiveNow == true and lastChatActive == false then
Player:SetAttribute("chatBoxHiddenConfirmed", false)
chatActivatedAt = tick()
elseif chatActiveNow == false and lastChatActive == true then
Player:SetAttribute("chatBoxHiddenConfirmed", true)
end
if chatActivatedAt and tick() - chatActivatedAt > 4 then
local lastFocus = Player:GetAttribute("lastFocus")
local timeSinceLastFocus = tick() - lastFocus
local ChatInputBarConfiguration = game:GetService("TextChatService"):FindFirstChild("ChatInputBarConfiguration")
if timeSinceLastFocus > 4 and not ChatInputBarConfiguration.IsFocused then
StarterGui:SetCore("ChatActive", false)
Player:SetAttribute("chatBoxHiddenConfirmed", true)
chatActivatedAt = nil
check = nil
else
check = tick()
end
end
lastChatActive = chatActiveNow
end)
2 Likes
This policy going into effect before cross-server messaging can be supported is a major misstep, in my opinion. I’d like to believe that cross-server messaging is a somewhat more common use-case than many would believe it is, and outright blocking it is something that is absolutely devastating for some developers such as myself who rely on it heavily in my in-dev projects.
Ideally, there shouldn’t be any policy updates made that affect legitimate developer use-cases as it unfortunately makes this platform a much more risky place to develop on (IE: What is to say that all of my experiences won’t be ToS compliant next year?); delaying the policy update (or excluding those use-cases from moderation) until said use-cases can be supported is almost always preferable for us as developers and our job security.
3 Likes
No, I meant that you can use Chat:Chat() in a SERVER script but you can only use TextChatService:DisplayBubble() in a LOCAL script. I am forced to go through every single script and add a bunch of extra logic just to get text bubbles to display properly.
I guess use remote events to call all cilents to display bubbles will do the work?
Your games aren’t being moderated for using legacy chat, they would be moderated if you didn’t migrate your chat system over to use the new APIs.
I want to see if I’m understanding TextChatService properly, specifically in regards to private channels vs public channels. Say I make a party system, and when a new party is created, players are also added to a channel for that party. But User A for one reason or another can’t talk to user B, while they are both in the party.
If user A chats and I send their chat through TextChannel:SendAsync(), do I need to worry about checking permissions on who they can chat with, or will TextChatService do all that work? In other words, will User B’s client ever receive that message, and will the relevant events ever run on their client for receiving the message?
I am not a big fan of the new chat system and prefer the look of the old system. While I do understand that it is probably needed I would really like if experiences that have legacy chat turned on could have the chat look the same but use the back end for the new system.
Also I liked getting creative with the old system, the new system (as far as I know) could never do something like this!
I feel like this update simply takes more control away from developers which is sad too see, I think developers deserve more freedom over their experiences, they way they look, and how they function. More control over certain core Roblox features is something that really feels needed.
I also dislike how invasive the Roblox ui is becoming. My game project somnia is an exploration game that aims to immerse the user in dream worlds. The game’s ui is designed to never be shown unless needed or the player chooses. However the top bar as you can see, takes a sizeable chunk of the screen, its even more now that there are 2 chat icons?
The top bar icons used to be a simple Roblox icon and chat button, now their are 4 buttons, and as far as I am aware, we developers have no way to change this back too 2 buttons.
Oh and uh the fact that the chat icon was swapped and this new out of experience chat thing uses the old icon is VERY confusing
Like I am not sure who thought that was a good idea but I find myself clicking the other button constantly if I’m not paying attention to it.
ok rant over
1 Like
why would you decide to ban games that doesn’t switch to TextChatService, especially if some games may have a inactive developer, or a developer that passed away for not switching to TextChatService, please reconsider this 
would you rather have Source Sans Pro & the 2016 look with transparent dark gray colors and square corners instead of the current design? I know you love Legacy Chat’s look for nostalgic purposes, but there is a custom chat made by @AdvancedOpenGL that emulates the old design while having the new chat backend
1 Like
Wasn’t the new chat supposed to be optional? Maybe fix the new one first before enforcing it on everyone
Some messages are still partially hidden due to the padding as visible in the screenshot
6 Likes
Cool, but TextChatService customisation is still lacking.
On top of that I would like to highlight that BubbleChatMessageProperties is missing some properties that BubbleChatConfiguration has. Specifically distances, offsets, spacings, duration, you get the idea. It’s not a 1:1 reflection of Configuration class and it bothers me.
Btw, LegacyChatService did let you customise MaxDistance and TextChatService does not.
ChatWindowConfiguration’s TextStrokeTransparency also has no effect regardless of what you set it to and there’s probably a whole lot more broken and inconsistent things which we of course could do nothing about because it’s closed source.
The truth of the matter is that despite this chat project existed all the way since 2022, it still got problems that weren’t taken care of and it’s why so many of us refuse to switch.
2 Likes
To be honest, these UI bugs are making TextChatService somehow annoying to use. There’s nothing like that with the Legacy chat.
1 Like
You do not have to use the base TextChatService API as clarified here, you can completely make your own UI; you just have to use TextChatService/TextChannel backend instead of remote events.
You can accomplish this with a custom UI while passing rich text data in the metadata.
I use remotes for communicating messages that have their own speaker, message type, message color, send type (server or player?) in a completely custom chat system (I am not using LCS or TCS). How exactly am I supposed to transfer all of this necessary data with TextChatService?
It goes like this:
Client fires message to the server with data telling it that it is a player
Server verifies this information, checks if the player has any gamepasses, assigns the message a color
Server sends that message to all clients so they can display the message along with a custom chat bubble
My game is a fast-paced, round-based retro fighting game. The server also needs to send chat messages to players, most of them often being complexly formatted RichText messages. How would I be able to transfer that with TextChatService?
nope, you dont have to worry about it. Users who cant talk to each other can be participants of the same TextChannel, but they won’t have messages delivered between them. Its all handled for you in a way that you don’t have to think about these specifics.
1 Like