This is good, itsss good finally theres a filter and plus its a fine update
Thanks for sharing those details, attributes are a solid approach!
A method like this would be greatly appreciated. I didn’t quite highlight it before, but because TextChatService.OnIncomingMessage
only takes a single function (similar to onInvoke
for a remote function), this means only us (the third party application) or the game owner can use it.
At least with an additional method such as SetPlayerDefaultTextChatMessage
, we could force a default appearance/behaviour for players (such as if they’re an Owner, HeadAdmin, etc), while the game developer taps into OnIncomingMessage
to customise specific TextChatMessages.
To be honest, this would be an amazing feature to customize the Chat Ui, especially for horror games that need the entire screen. I did realize that on 16:9 displays the Chat Ui is quite large.
TL;DR
This would be useful.
My main concern is setting chat color interacting with bubble chat.
I am using
local FORMAT_CHAT_COLOR = "<font color='#%s'>%s</font>"
properties.Text = string.format(FORMAT_CHAT_COLOR, chatColor:ToHex(), message.Text)
to set the chat color.
This works in chat, yes. However, in bubble chat, it shows the entire string (assuming bubble chat doesn’t use rich text). There are likely workarounds, however, I was curious if there are plans to include native workarounds?
Edit: After looking around in the CoreGui chat box, a possible solution is to create a method or property called MessageColor
that would change the color of the entire TextLabel. It’s a little jank with the :
but just throwing stuff out there.
Some stuff that Ive found with this:
- The transparency doesnt match the topbar.
- The chat sometimes fades out incorrectly, making the text fade out before the chat box or the chat box fading out when Its still hovered over
- It seems there is no way to remove a user from a channel.
- The chat is very wide on larger screens.
- The send button and chat bar text colors are wonky sometimes.
- Why does the send button use a UIListLayout? You could just set the anchor point to 0.5, 0.5 and position to 0.5, 0, 0.5, 0
- RichText still doesnt work with chat bubbles.
- There is no whisper feature. (Is this removed, or not implemented yet?)
- The chat bar border is cut off at the end. Changing the bottom padding to 0, 1 fixes this.
(default)
(with bottom padding)
Perhaps this could be a bool in ChatWindowConfiguration? I dont see why not.
Also, shouldnt ChatWindowConfiguration.Enabled = false
make the chat box invisible, but the chat bar still visible? The legacy chat had an option for that, so I dont see why the new one behaves like this.
By the way, whats with the inconsistent name capitalization of the chat? lol
Overall, this is really nice, and if more customization is released then this will be absolutely awesome.
Even if the kinks of the default UI arent fixed, you might as well make a custom chat and use the new functions for sending and recieving messages.
And speaking of that, do you have to filter the text thats passed to :SendAsync? Or is it done automatically?
I made a tutorial if anyone does not know how to use this since docs aren’t released.
Just a quick one.
Sorry for self promoting but I thought it would be useful
I have never seen any game implement localized commands. Even professional programming languages such as Python and TypeScript are used all around the globe without localization. Not even Windows Powershell has localization. Commands should remain universal for all users, and there are no use cases for localizing commands.
I’m actually looking forward to this! This is a massive improvement from what the Roblox chat is now like, looking forward to the release!
I have no complaints about this update. I believe I should be able to adjust the very dark chat colours. The API should prove useful for developers.
I’d like to ask to make TeamChat, but with multiple teams possible by using the API
Something like this:
TextChatService:CreateCustomTeamChat("TeamChatName", {Team1, Team2, Team3})
This would be very meaningful to me.
Again: speak for yourself. Not everyone follows “industry standards” and this was just an offhand remark that regardless, it should remain the developer’s choice, not at the whims of some dogmatic standards.
Personally, localisation isn’t as huge a concern for me here as it is being able to have more than two aliases to a command. A CSV would allow me an unrestricted number of aliases so I can control how a command gets referred to as. It also avoids property bloat (I am NOT checking two properties if I ever need to reference an alias when one could suffice).
Being able to have (nigh) absolute, unrestricted control of chat behaviour is what appealed to me with the Lua Chat System. I would like to see the same for TextChatService. There are cases where indeed there are no genuine use cases for doing something, but this is not one of those cases - this should remain up to the developer’s discretion. Doesn’t matter if professional venues don’t localise at all, that is entirely irrelevant.
I don’t want to keep up a discussion about subjective semantics on why something should or shouldn’t be allowed.
Xbox ROBLOXians should 100% be able to chat in some way, whether it causes them to be heavily censored by this new text service to keep it “pg 13” or not.
Some games have already been created specifically to let Xbox users have a voice. The Xbox stereotype gets worse every year, I think it’s time for ROBLOX to fix it.
That is not going to occur probably as I think it has to do with ESRB rating things as roblox on Xbox is considered a game instead of a platform
Hello there. I would like to address a few of my concerns that I have discovered in this beta. These could range from a lot of things, but I will just simply display my problems I have currently here:
Chat Commands
Now, I like the inclusion of instance based chat commands, but one problem is the limited amount of aliases possible with this command. As currently seen, there are only 2 aliases available. However, what if a value existed for chat commands which allowed for… a dictionary of chat commands to exist in 1 value? As an example:
local SizeCommand = path.to.SizeCommand
-- For more than one command, we set aliases in a dictionary.
SizeCommand.Aliases = {
"/scale",
"/size",
"/grow",
"/giant"
}
Alternatively, setting the dictionary of commands can be done via a property in explorer. This seems like a more effective method than having just 2 command aliases.
UI
The UI currently in the chat feels a bit too distracting from all the surroundings in game by blocking up quite a lot of screen space. For context, the color that is being used for the main Chat window is a color called “BackgroundUIContrast”. This color is essentially rgb 0,0,0 but with a transparency of 0.3. As the name suggests, it is for backgrounds on UI, but with contrast . Does Roblox’s chat fall into this case? NO.
Roblox’s chat UI should not fall within this category. Simply because the chat should not be contrasting from the actual gameplay itself. As well as that, the color is too dark which results in a large portion of the screen being covered up by this. Think of the old chat. The old chat was FAR less dark than this chat is. So how about you use a color… like BackgroundOnPress? While this correlates to the background of the UI being pressed, it would work far better for the chat than the current color does.
- Easier color on the eyes
- Less distracting and more transparent
- Doesn’t hide a larger portion of the screen.
UX
Some of the UX in the new chat is… awful. For example, the text box is not fully scaled with the background. This results in this happening.
This should not be happening, and instead the textbox used for chatting should be full height of the box. So, without that full height, this happens.
Overall, I’d rather prefer full heighted text boxes than this. Oh my oh my.
I don’t really have a lot of problems with this new update. Hope some of this stuff gets fixed!
The set core does not work on the new Chat
local textchatservice = game:GetService("TextChatService")
textchatservice.OnIncomingMessage = function(message)
if message["Status"] == Enum.TextChatMessageStatus.Success then
game.StarterGui:SetCore("ChatMakeSystemMessage",{
Text = "Your message has been sent",
Font = Enum.Font.FredokaOne,
TextSize = 25
})
end
end
Proof that it does not work in the new chat
This looks great! All I’m missing is a server equivalent of OnIncomingMessage or SendingMessage.
I have a use case where I would like to filter messages for players on different teams, similar to the cross faction chat in WoW. Although it would require exposing who the message is being sent to. Reason this wouldn’t work on the client is that I can’t filter out bad words reliably.
Woah! How did you add those cool profile pictures?
Can we all agree that Roblox just comes out with the best studio betas?
This is amazing! I am very excited to see Roblox supporting more intuitive ways to use chat commands! It is also such a relief knowing that all the policy stuff will be taken care of for us. No more worrying if we forgot to filter a chat message! It’s always nice when we get more customizability to core Roblox systems without having to fork the entire thing.
I remember a few months ago I wanted to do some minor edits to the chat system but realized I would have to fork the entire chat system so just gave up. This update makes everything so much easier and makes me excited to see more updates in the future to the chat system!
You can use TextChannel:DisplaySystemMessage instead now:
message.TextChannel:DisplaySystemMessage("Message sent successfully!", "Custom.Test.Info")
local textchatservice = game:GetService("TextChatService")
textchatservice.OnIncomingMessage = function(message)
if message.Status == Enum.TextChatMessageStatus.Success then
if message.TextSource then
message.TextChannel:DisplaySystemMessage("Message sent successfully!", "Custom.Test.Info")
else
-- Probably a system message
if string.find(message.Metadata, "Info") then
-- set TextChatMessageProperties and return with font choice
end
end
end
end
Also had your previous code worked, you would have set up an infinite loop, so be careful. The code above avoids the infinity loop by checking for TextSource.
Normally I think best practice would be to avoid creating more messages within the callback and use the callback strictly for formatting messages by reading the message properties.
I like how OnIncomingMessage helps encapsulate all the formatting logic for fonts and text styles now instead of having it at each callsite in the game!