Please check some of my responses regarding channel tabs within this thread for more information.
2 Likes
Will custom chat systems still be able to be created after this is “required”?
Themes are definitely a needed feature. While I wouldn’t see myself using this, some developers may want to mimic the look of the old TextChatService when making a nostalgia game.
3 Likes
Please! I want to make my chat bubbles rounder.
I’m not sure how I can get any more clear than “what do you mean by required”, it’s a weird word to use without explaining the scope of “required”. I can’t exactly make specific questions because the wording itself is ambiguous and confusing to have put in the thread. “Required” implies there’s some sort of requirement on the developer’s part to acknowledge this, or I don’t know?
Primarily, I literally want to know why the word “required” is used in the communication. What do you mean when you add that line? Do we have to use the new chat system? Is there some kind of developer policy that will result in moderation action for not using it? Will we be forced to use TextChatService as our custom chat backends and not be allowed to write custom chat systems anymore?
I feel like it should be your job, as the communicator, to explain what “required” means initially. Why did you choose that word, why is it in the thread, what is it trying to explain?
The only question I can ask about this is why it’s there. I can’t form specific questions until you yourself explain what “required” means in the context of the chat system and why you chose that word to appear in the thread. It’s incredibly confusing just being there, so I think the inability to comprehend this goes both ways. I can’t understand it, and in turn I can’t ask good questions about it.
“What do you mean by required” feels adequate enough to ask, because there’s no explanation as to what “required” means here at all. Nothing about policy, prohibiting use of other chat systems or anything. I think you need to clarify or remove that before I can go into depth with that. If you yourself are unable to answer why “required” is there, how can I ask more concise questions about it?
Again, the thing here is that the chat components are still now baked into my experience. LoadDefaultChat prevents any chat processing from both the server or the client besides any internal events watching for chats (e.g. Player.Chatted). Disabling the bar and window via their configuration instances is adequate for gameplay purposes, not for technical, unless you can clarify that no processing is done by TextChatService when either are disabled (and therefore no running processes by these inactive components).
Thank you otherwise for the response and insight into the long term vision and plans for the TextChatService.
6 Likes
Yes, TextChatService is actually also meant to make custom chat implementations easier.
Amazing feature, much more easier to configure than the old chat system, thanks Roblox! I’ve actually migrated to it and it was pretty easy, love the text commands too 
Just having an issue, the previous chat system frame was a descendant of PlayerGui, which I could access to edit the chat textlabels through the script, and now I don’t find the gui for textchatservice messages… I was using that to implement UIGradients into the certain announcements so now I have to find another way around it
Why is TextChannel.MessageReceived client-only? It seems that the only way to get all of the properties of a message on the server is to use ShouldDeliverCallback, which feels a bit roundabout.
Thank you for your response and rest assured it will be taken into consideration in our future messaging.
I am an engineer by trade, and despite developer relations and external messaging being beyond the scope of my responsibilities, as one of the many contributors to this initiative, I felt compelled to maintain a higher level of engagement for this project. I can now imagine why some individuals in similar situations may not be as motivated to reply to messages.
Follow up question: I am unsure why disabling the bar and window is not sufficient for certain use cases. The “internal events” you mention are triggered when messages are sent via TextChannel:SendAsync or the default input bar (which is technically equivalent). If the elements are disabled and there are no Lua runtime code that calls any relevant API, there shouldn’t be any chat processing. Can you clarify why the configuration instances are not sufficient (technical or otherwise) for your needs?
5 Likes
We are exploring adding support for additional UI elements customizations, including gradients
1 Like
By custom chat systems do you mean systems that use TextService:FilterStringAsync? Or systems that use TextChatService and related API such as TextChannel:SendAsync?
Systems that use TextService:FilterStringAsync(). I assume custom chat implementations using that are unaffected?
Ohhh I see! Will definitely look into that later :3
That is completely alright. The use of the word required just confused me as to if there were any instructions that we as developers would’ve had to commit to as opposed to having choices. For example’s sake, when an update says required, I may think a list of things. Two common thought examples, although not limited to these two, could be the following:
-
If we do not follow a set of instructions given on a thread, we may receive moderation action. For example, the creation of PolicyService and updating developer policy to mandate us to use for certain features such as the external websites a player is allowed to see.
-
An update plans to supersede and remove old behaviour and thus we need to make preparations. For example, many years back when FilteringEnabled was introduced to enforce the client-server model, we were given a period to convert our new experiences to be compliant before the toggle was removed and the behaviour with FilteringEnabled=true became default.
My confusion is primarily generated from the thread describing a contradiction: it says that existing experiences will not be affected and the Legacy Chat Service will be deprecated, but also says “require TextChatService” as a subpoint to the deprecation, which leads me to believe that I would not be allowed to use the old chat system anymore. It’d be weird to simultaneously not require any changes to existing experiences and require that we use TextChatService at all.
If by “We will not require TextChatService for new experiences until a majority of developer needs are addressed” you meant that TextChatService will not be enabled by default until developer needs are addressed, I think it would be suitable to change the wording there from “We will not require TextChatService for new experiences” to “We will not enable TextChatService by default for new experiences”. It helps it be more clear about what the upcoming behaviour will be rather than implicate policy or a need for developers to change their systems. Though I can’t be certain what is meant by “required” because my interpretation would contradict the title and content body which says that TextChatService is already the default for new experiences.
This is probably what I should’ve mentioned at first when you followed up about me asking for explanation about the use of the word “required” in the thread.
It’s not always easy to communicate changes but the fact that you’re upfront about your own responsibilities and participation in the new communication initiative helps me better know that we can reach the people responsible for delivering updates and know our feedback is actually worth expressing. It’s difficult but I’d prefer this over no communication at all. A good exchange can help us, developers and staff, build a better platform in lockstep. I don’t want to discourage any staff from opening up so it means a lot to discuss these things at lengths.
Thank you for this. Thinking back, this same flow applies to the Legacy Chat System as well (e.g. no chat processing if the chat window/bar are disabled).
I think my thoughts were tunnel visioned on the fact that there are still chat components being executed when the Legacy Chat System was loaded and disabling LoadDefaultChat prevents any server or client components from executing, so it’s not just disabling client requests to API but also from any API backend from existing to begin with. That’s essentially the behaviour I was looking for here; no chat processing, let alone any code at all related to chat.
It’s not a necessity to have and disabling the client elements from the configuration instances is enough for me, but generally in experiences where I don’t have chatting enabled or create a system from scratch, I entirely remove out the chat components. This means that there’s no observation from Lua or the engine on chatting in any capacity (e.g. memory, thread profiling, existing remote events that could be fired, unused Roblox or pure Luau instances, etc).
In other words: with the Legacy Chat System, I can disable LoadDefaultChat and the engine would not inject any chat components at runtime at all. With TextChatService, the only option available to me is disabling client interfaces with the configuration instances rather than to prevent the entire system from loading.
6 Likes
Can you please make a notification saying that the user can’t talk if CanSend is false? I was trying to test a mute command and I was puzzled on why it wasn’t working, turns out CanSend only applies to the chat replicating messages to other people
Not sure if anyone has reported this yet, but when someone chats on mobile, I keep having to scroll back down to the bottom every time to see it. Even after being scrolled completely down, another chat message will appear and i’ll have to scroll down again. I believe this issue only happens on mobile and not on PC.
It’s slowly coming out, parts of it is already added
4 Likes
Best change in a long time! Thank you so much!
This new text chat system is inconvenient for proximity chat use cases.
My goal is to create a chat system where if a player sends a message, only the players within range of the sender should only be able to see the chat message (and bubble). I am aware that I can just create a new text channel and place all text sources within it. However, using this method for proximity chat would not work so great because I would have to create a new text channel per message sent.
If there are 100 players in a same area, and they all send a chat message, it would be redundant to write code that automatically creates 100 different text channels with 100 text sources per channel. Imagine if there are 700 players in the same area, I can’t begin to imagine how it badly it could affect performance if they each sent a chat message at the same time.
I saw a few games have tabs with a chat that looks like the new chat service? I assume this is custom 
5 Likes