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.
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.
@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
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)
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.
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.
I think match is a better. It saves more time
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:
(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