There is no point to filter in Studio, especially in a solo session (not team test)
It’s also a big waste of resources
5 Likes
From what I understand, the chat filter isn’t active in Roblox Studio playtests so that players aren’t able to quickly test as many bypasses / filter workarounds without the risk of account moderation. I’m not fully sure about that but that’s the most reasonable conclusion I’ve heard / thought of.
If I remember correctly, around the timeframe when the Spatial Voice Chat Developer Beta started, a “Chat Filtering Level” setting appeared in the “Privacy” section of the account settings page.
Currently it’s locked and unable to be changed (as far as I’m aware) but it appears to be a drop-down menu that will eventually allow players to choose between different filtering levels (<13, 13+, and maybe 18+ if ID verified with an account birthday that’s at least 18). Not sure if that will happen but it seems more likely than ever considering it’s an official setting.
7 Likes
Totally agree, there should be age rating controls allowing experiences and communities to mark themselves as for older audiences.
I believe this was briefly touched on in RDC but it doesn’t seem Roblox has done anything about it since. Hopefully we will start to see this in the near future as Roblox continues outgrowing it’s founding kids games by kids ideas.
6 Likes
It would be more confusing to see filter working in a solo session.
1 Like
It’s great to see that the chat is finally getting an overhaul, and the current chat api is pretty hard to work with, so this is definitely a welcome change. I’m also wondering: will this make current admin command systems obsolete?
Similar to the feature request about simplifying the new Bubble Chat Settings, can we expect API methods to make the customisation of chat features, such as PrefixColor, much simpler?
For instance, to customise the PrefixColor, TextChatService currently requires developers to do the following on the client:
-- LocalScript
--!strict
local TextChatService = game:GetService("TextChatService")
local getColorFromName = require(script.getColorFromName)
TextChatService.OnIncomingMessage = function(message: TextChatMessage)
local props = Instance.new("TextChatMessageProperties")
if message.TextSource then
local colorHex = getColorFromName(message.TextSource.UserId):ToHex()
props.PrefixText = "<font color='#" .. colorHex .. "'>" .. message.PrefixText .. "</font>"
end
return props
end
This becomes additionally complex and messy as developers introduce features such, as a chat color gamepasses, which often require the developer to verify the information on the server, and to continuously replicate this information to all clients as more players join and leave the game.
This could instead be simplified with server sided methods which simplify the whole process:
TextChatService:SetDefaultTextChatMessage({
PrefixTextWrapper = "<font color='rgb(255,165,0)'>%s</font>",
TextWrapper = "<b>%s</b>",
})
TextChatService:SetPlayerDefaultTextChatMessage(game.Players.ForeverHD, {
PrefixTextWrapper = "<font color='rgb(255,165,0)'>%s</font>",
TextWrapper = "<b>%s</b>",
})
Third party applications could then check for defaults by the game owner and handle them appropriately with similar Get methods:
local textChatMessage = TextChatService:GetPlayerDefaultTextChatMessage(game.Players.ForeverHD)
Chat customisations are widely used within HD Admin (to highlight the owner of the game, staff members, VIP roles, etc) so anything which makes this process easier without having to worry about conflicting or overwriting the game owners default configurations would be greatly welcome.
More details and examples here:
It’s great to see the chats customisability being opened up and improved with this new service so thanks very much, excited to all the new methods in the upcoming weeks!
17 Likes
While this is really cool, its a bit disappointing that the layout is still generally the same.
I forked the old chat to make this:
Its a shame this isnt how the new chat is like, and you cant do this with the new chat either
Also, is whispering removed? Or is it just not implemented yet?
1 Like
Small feature request: Can the Alias props on TextChatCommand be a CSV list, and not restricted to two aliases, it seems a bit limited over the original ChatService.
The original ChatService, even though it didn’t natively have commands, we could bind as many aliases as we wanted to one command. With this current implementation, its impossible to add localisation aliases, among other things. since we’re restricted to two.
11 Likes
Why localize chat commands in the first place? Don’t act like Roblox’s automated localization bot, it would only look weird and would create more issues for your game’s wiki editors (if there would be any)
I think that’s at the developer’s discretion if they want to do that. Speak for yourself. 
Automatic localisation isn’t really powerful in every case and a CSV list for command aliases would be great especially if you want more than one aliases while localising; there may be more than two ways that we want a command to be referenced by and a CSV would help with that.
5 Likes
@Roblorcah how would we add more than 1 argument with the new API for the chat commands?
I can make a kill command like this which only requires the target player which we don’t even need to define
/kill valiantwind -- this works
but how will I be able to add an extra argument for the new API. I’ll be using a speed command as an example. The target player is automatically set, but I don’t know how to set the walkspeed for the player.
Here’s what I mean:
How would I be able to script something like this with the new TextChatService API:
/speed valiantwind 100 -- The 100 is the extra argument that I don't know how to script
2 Likes
Maybe something like this?
local argv = string.split(command, " ")
local argc = #argv
was going off C naming for the main function
so, for your speed command, it’d probably be something like
SpeedCommand.Triggered:Connect(function(source, command)
local argv = string.split(command, " ")
local pName = argv[1]
local speed = argv[2]
local Player = Players:FindFirstChild(pName)
local Char = Player and Player.Character and Player.Character.Humanoid
if Char then
Char.WalkSpeed = tonumber(speed)
end
end)
4 Likes
This is great feedback and it’s great to hear from your perspective, specifically.
A low-cost, low-effort way to support chat-color via gamepasses is to use SetAttribute/GetAttribute on the Player object or even the TextSource object and have their OnIncomingMessage callback reduce the color from the attributes. We do something pretty similar in one of our demo files, VIPDemo.rbxl.
-- server
local function onPlayerLoad(player, data)
if data.ownsVipGamepass then
player:SetAttribute("isVip", true)
end
end
-- client
-- Observe the world state to format messages for our client
local TextChatService = game:GetService("TextChatService")
TextChatService.OnIncomingMessage = function(message: TextChatMessage)
local props = Instance.new("TextChatMessageProperties")
if message.TextSource then
local player = Players:GetPlayerByUserId(message.TextSource.UserId) -- maybe TextSource:GetPlayer() would be nice?
if player and player:GetAttribute("isVip") == true then
local colorHex = Color3.fromRGB(255, 0, 255):ToHex()
props.PrefixText = "<font color='#" .. colorHex .. "'>" .. message.PrefixText .. "</font>"
end
end
return props
end
This would handle your replication issue automatically through the Instance’s Attribute APIs. For our initial proposal, we attempted to be as conservative as possible when introducing new surface areas for APIs and attempted to leverage existing technology (such as RichText tags and Attributes) with room to expand.
We had considered a server-side OnIncomingMessage callback but it got a little tricky to define for the initial release for a few reasons. The primary reason is that OnIncomingMessage on the server falls apart when you introduce filtering. The Text value for each recipient could be different depending on current or future filtering rules.
Your SetPlayerDefaultTextChatMessage proposal is worth following up on as it would allow server scrips to define a global configuration authoritatively. It does run into the same issues as allowing conflicting or overwriting previous settings, but could be a valid direction to move towards if the need is there.
10 Likes
Yup, string.split helps a lot in this case. You’ll probably want to make sure you cast speed as local speed = tonumber(argv[2]) and make sure it exists otherwise you may run into typing issues.
5 Likes
I think match is a better. It saves more time
2 Likes
This is good, itsss good finally theres a filter and plus its a fine update
1 Like
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.
8 Likes
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.
3 Likes
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.
12 Likes
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)
(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?
10 Likes