One thing I think should be changed is the name of the textbox in which you type chat messages. Currently it’s just called “TextBox”, but I think it should be called “ChatBar” just like the old one.
I’ve seen a ton of games use this name to check whether or not the player is typing in chat, so I think this would be a good way to keep it backwards compatible.
Edit - an annoying bug:
For one of my friends and I, we now have to press “-” as opposed to Shift + 7 to chat. This works fine on my Danish keyboard but on his Spanish keyboard, it always adds a minus to the beginning of his chat message:
How do custom commands work? Could you provide us with a quick documentation for the RegisterProcessCommandsFunction method (specifically the function you pass in)?
Thanks for that tip on naming the box “ChatBar”. I didn’t consider that at first, but I can see why it would be useful.
As for that typing bug, that was because the beta release used UserInputService.InputBegan instead of the GuiService.SpecialKeyPressed. This issue will be fixed when this new system is rolled out for real across all games.
The function declaration for the function you pass in to RegisterProcessCommandsFunction is this: ProcessCommandsFunction(speakerName, message, channel) where “speakerName” is the name of the speaker saying the message, “message” is the exact message being said, and “channel” is the name of the channel the speaker is saying this message in.
The ProcessCommandsFunction is supposed to either return true if this function processed some command from this message (and therefore the actual message should not be shown to everyone), or false if this message had nothing to do with this function and it should just pass through.
The example I’ve linked below is for an admin commands script. It returns true if a player tries chatting a message starting with “!”.
You could also use ProcessCommandsFunctions to do other cool things such as custom message replication to clients. The team chat module is implemented this way. Every single Speaker is in the same Team channel, but a ProcessCommandsFunction has logic in it to determine which speakers to send the message to (and then it returns true to let ChatService know it already took care of it).
You already can use RegisterProcessCommandsFunction for just a single command. You can register functions to handle entire sets of commands, or a function to handle just a single command.
For example, you could do:
local function ProcessFunction(speakerName, message, channel)
if (message == "/reset") then
--// kill player
return true
end
return false
end
ChatService:RegisterProcessCommandsFunction("reset_command", ProcessFunction)
Autocomplete for player names when doing /w playername
Autocomplete for commands when doing /command
Autocomplete for custom commands (not possible with current API since it doesn’t know what they are, but maybe you could tweak it a bit so that wasn’t the case)
The API seems to use speaker names everywhere. Why aren’t there those Speaker instances passed around? Using player names sounds like asking for conflicts, iirc multiple things have the same name… E.g. a XBone names vs Roblox account names (although they don’t share servers currently, I think) or multiple Guests with the same id/name. A player sharing a bot name is another potential conflict.
Seems like the chat message is created using a bunch of spaces after the player name, this sometimes results in inconsistent and noticeable spacing differences between the chat message and the player name.
Chatting doesn’t feel responsive as locally sent messages don’t appear immediately (maybe update them once filtered?).
Animations are super slow.
A built-in more comprehensive command parser would be great.
This is how it works in the current ROBLOX chat as well. The message label could be positioned directly after the name label, but you run into the issue that now multi-line chat messages don’t wrap how they do now. They start at the end of the sender’s name on each line instead of wrapping to the edge of the window. The chat has to use spaces so that it can both wrap at the edge of the chat window and also start the first line after the sender’s name.
I agree with all of these. Here are a couple of things I’m requesting:
I had the same problem with using usernames as the “uniquely identifiable id”. I’d like to use a generated id, and have some sort of call that would convert name to generated id (and handle duplicates in that case).
Got a bunch of requests to make a “message sending” or “typing message” animation.
I’d also like some sort of parsing service to have
It’s just an observation I made and thought it was really ugly.
Alternatively they could consider using U+200A for their “space” now the labels support unicode. game.StarterGui.ScreenGui.TextLabel.Text = string.char(0x20, 0x0A); print(game.StarterGui.ScreenGui.TextLabel.TextBounds)
2, 28
Will look slightly more consistent, at least. Maybe in combination with another space with odd width for the pixel perfect alignment (and ultimate hackyness).
Dunno. My internship ended at Roblox and I wont be back until like mid June 2017.
It was looking like it was pretty much good to go, but then product team wanted a redesign for the UI. I think there may also be a few minor problems left over that still need to be looked at.
I believe it was supposed to be passed on to either @spotco or @TheGamer101, but I have no idea what kind of work has been done on it since I left almost 2 weeks ago now.
(and ultimate hackyness).