TextChatService is now the default for new experiences!

Updates Announcements
#52

Can you elaborate what you mean by “channels and developer UI injection portals”?

#53

I have talked about this a lot in previous threads about TextChatService. Since the last time I checked, there was no built in UI to change between chat channels, and there was no way to mod the chat UI with additional buttons so adding this functionality myself in a cohesive way without totally separate UI is impossible.

Replies with context:

Chat Feedback - Whisper, Performance and Customization:

2 Likes
#54

You can change the TextColor and BackgroundColor of all the bubbles at once, but it would be nice to change the TextColor for a specific chat bubble, or at least from a specific person. For example, a VIP or Admin would have gold text, but everybody else would have normal text. It would also help if we can change the voice chat icon image color, and mic volume color.

4 Likes
#55

This isn’t exactly a deal breaker for me, but currently it’s pretty difficult to design UI around the new text chat window because of a few reasons:

  1. WidthScale and HeightScale properties of ChatWindowConfiguration are poorly documented and their behaviour is pretty counterintuitive. Based on their description and on how other UI objects behave, I’d expect them to be a fraction of the screen’s size, but that’s clearly not the case as their default values are 1 but the chat window doesn’t scale across the entire screen.
  2. The new chat window always displays over custom GUI items.
#56

Scale the width and height.
Configure the chat window.

It is in CoreGui.

#57

If you can list out specifically what questions you’d like to be answered within the scope of "required’, we would appreciate that, instead of “what do you mean by “required””. We would like to be clear and concise in our messaging and if you have any specific questions regarding this we’d be happy to take those into account during our multi-month rollout of TextChatService.

With respect to some the questions that were specific enough for comprehension and appropriate response:

Non-player TextSources: We’re currently working on this and designing the appropriate API to make this a seamless experience that aligns with some long-term initiatives. We hope to get this resolved soon.
Channels: As you are aware TextChannels are currently available. We plan on rolling out Channel tabs UI to make channel switching easy without calling any specific API from the developer’s end. We also plan on introducing more step-by-step tutorial-like guides to clarify TextChannel usage. As you may be aware we’ve been revamping our documentation and you probably have noticed we’ve significantly increased the amount of resources available for guides on customizing chat elements.
Clear: This is also something we’re investigating! As you may have noticed, we’re taking a phased approach and methodologically reaching parity with the legacy system. We prioritized the most frequently used features and interfaces. We’re happy and confident that we’re now in a position to tackle some of the more uncommonly used aspects (such as clear) of chat and we’re excited to be moving on to these parts.
LoadDefaultChat: Have you looked into ChatInputBarConfiguration.Enabled and ChatWindowConfiguration.Enabled? If you have, how does this not address your needs?

As you are well aware, we’ve been consistent and long-term with our communication with TextChatService rollout:

We aim to continue this level of correspondence with the community and address any issues and questions. To help us better serve this goal, we appreciate your continued clear and communicative responses.

#59

We haven’t provided a specific timeline for channel tabs, but we do hope to introduce some form of a timeline with features now that some milestones have been met and TextChatService is default for new experiences (and hence, a lot more visibility + demand for details). We appreciate your patience as we try to scale the system and balance various requests and internal initiatives.

Deprecation does not mean complete removal or loss of function, so we would appreciate some clarification for what you mean by “significantly decreased my workflow”. We would like to investigate edge cases and see how our rollout impacts unique, uncommon flows to better cover all developers.

3 Likes
#60

Please check some of my responses regarding channel tabs within this thread for more information.

2 Likes
#61

Will custom chat systems still be able to be created after this is “required”?

#62

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
#63

Please! I want to make my chat bubbles rounder.

#64

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
#65

Yes, TextChatService is actually also meant to make custom chat implementations easier.

#66

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 :smiley:

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

#67

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.

#68

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
#69

We are exploring adding support for additional UI elements customizations, including gradients

1 Like
#70

By custom chat systems do you mean systems that use TextService:FilterStringAsync? Or systems that use TextChatService and related API such as TextChannel:SendAsync?

#71

Systems that use TextService:FilterStringAsync(). I assume custom chat implementations using that are unaffected?

#72

Ohhh I see! Will definitely look into that later :3