Will the legacy chat system ever be removed, or will I need to fork it?
Is it possible to utilise the TextChatService functions for a custom chat GUI?
Just to clarify, even if I make ShouldDeliverCallback return true from the server, will the text filtering system still check the message before sending it to all clients?
TextChannel | Roblox Creator Documentation
Have you looked at this example for creating proximity chat? In Experience Text Chat System | Roblox Creator Documentation
Can we please have the TargetChannelChip (appears when you whisper to someone or in team/system chat) editable with our own custom Text Channels. I think it would be more user-friendly if this change happened
This colon behavior change should be live now!
You can already do this with TextChannel:DisplaySystemMessage
! (documentation: TextChannel | Roblox Creator Documentation)
The RichText issue has been resolved. Are you still encountering the scrolling issue on mobile?
Are you still encountering this issue? If you do, could you enter ā/vā in the chat and tell us what the chat version is?
Iām curious, is there a specific reason why the new chat is in CoreGui? Why canāt it be in PlayerGui?
Doesnāt seem like so in other games which use the new chat so I guess no.
Weād like to maintain the integrity of the user interface and associated instances so that we can provide a consistent experience for all experiences using the default chat UI.
We plan on regularly updating this interface with the appropriate set of API so that developers can still make customizations without having to create their own front end for the chat using TextChatService.
We understand that, historically, chat was in PlayerGui, but similar to the issues with a forked chat system, with a system like this we are unable to reliably roll out updates without compromising near infinite permutations in which developers may be dynamically adjusting the UI directly by changing the properties of the UI instances.
We want to support scalable ways in which developers can customize chat, and add additional API based on needs and requests, as opposed to the legacy layout.
Here is an example:
We may change the hierarchy and structure of the default chat UI for performance reasons (i.e. less instances, cleaner layout, less re-rendering, etc). However, if you relied on, say, a particular TextLabel always being within a certain structure, and modified that label in a certain way for your own needs, our optimization change would break your use case since the instances hierarchy has changed.
Instead of implicitly allowing unmaintainable practices, weād instead like to explicitly provide scalable API to help developers customize chat to fit their needs (and we understand this is a more difficult approach, but one thatās beneficial in the long term compared to our current situation).
I also have made a modification to the current chat UI like that as well!
Though mine is a side menu.
Hopefully, we can get something like this by default! A side menu like this would be better for seeing all the channels.
What is the purpose of the heightScale property on ChatWindowConfiguration? There is no documentation yet. Itās clamped to max of 2 which is woefully inadequate for an āexpand chatā button, and the amount it increases the chat size becomes almost nothing on larger desktop screens. Resizing the window smaller makes the amount it affects the size much more significant.
Very slick and customizable, thank you! Itās so much crisper too.
Unforked Legacy Chat
TextChatService
It is definitely not easier. Took 3 hours just to build my own sort of channel switching which shouldāve been easy if the chat was as ācustomizableā as they said it wasā¦ last year.
When the TargetTextChannel of a ChatBarInputConfiguration is set to a channel where the user has no permission to send a message, it just outputs a plain text version of the message with no username or even source, is this a mistake or an intended feature? If it is can you explain why as it has no use.
A major problem with the new chat UI being located in CoreGui is that we lose control of the rendering order, we canāt render any UI elements in front of the chat.
CoreGui currently always renders in front of PlayerGui. It would be great if ScreenGuis in the PlayerGui with a DisplayOrder beyond a certain threshold rendered in front of the TextChat UI, despite it being located in CoreGui.
Why does this new chat allow zalgo text?
Im not sure if previous chat did allow it, as I never saw it, but today I got a report of people abusing zalgo text in my game
It was always allowed; the old chat did have a character limit though.