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