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
2 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.
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