There’s no need for a betttaaaa! C’mon Roblox… let us use it in our games now
Very interesting, just a quick question on your demo.
I’ve never seen this before
function(message: TextChatMessage)
what does it do?
Also, disabling “ChatInputBarConfiguration” does not remove the chat bar.
This is a part of Roblox’s LuaU type checking.
That is just declaring that the message
parameter is of type TextChatMessage
.
I have two pieces of feedback atm, both based off this image:
-
The
TextChatMessageStatus
Enum seems to be missingEnum.TextChatMessageStatus.Sending
in its documentation. -
When a message is in
Sending
state, it still appears in chat. This is unlike the old chat system where it would “process” the message first (in this case, that would be usingTextChatService.OnIncomingMessage
) and THEN shows the message once the formatting and coloring is done. This is an issue because, since I am doing a lot of checks to see what the player’s prefix, name color, and chat color should be, it takes a few morems
than is in a single frame and therefore is put into the Sending state. In chat, it displays plain (I am adding the[]
myself) before “switching” to the formatted version given through the properties.
In Sending
:
In Success
:
It is very inconvenient and looks awkward/horrendous. It takes this much time in the current chat system, but players don’t see that because it doesn’t show the message until it’s done. The fact that I have enough time to take a screenshot proves that.
Yes, I can optimize it on my end more by caching stuff and just overall code quality. HOWEVER, not everyone wants to make the sacrifices related to caching when it comes to dynamic changes in prefixes and name colors. Plus, newer developers don’t know much about caching and if they are making their own systems based off this, it will have that awkward feel to it.
We wanted to have the chat feel responsive to players when used. However if you do not have all the information ready to format your player’s messages, it does come with this caveat.
It doesn’t look like it made this release, however we have plans to allow developers to filter out which messages appear in the ChatWindow from OnIncomingMessage
. This would allow developers to filter out system messages that are not relevant (example use case: How can I disable team changed system message?) or in your case, you would be able to optionally hide any messages with the Enum.TextChatMessageStatus.Sending
value.
Would something like that solve your problem?
Yes, absolutely! I was thinking maybe a boolean value on the TextChatMessageProperties
, something like TextChatMessageProperties.HideMessage
?
I agree with you that the current implementation does make the chat feel immediately responsive for players by default. A solution like this would keep that desired effect while also allowing developers to hide messages that they are still processing if they so choose.
The /emote
command will be supported in the 522 release.
In regards to chat colours: was the underlying code for picking colours a super long time ago (like, when I joined in 2009, not sure when it was removed finally) based on presumably username or user ID or something ever released to the public? Being able to repurpose those colour values for other stuff (say, to colour code what each player makes in a cooperative building game) would be nice.
In the LegacyChatService version, you can close the chat window by clicking the icon, and you can press forward slash to reopen it and start typing immediately. However, in the new TextChatService version, you can’t do this. You have to manually open the chat box and then press forward slash. Is this intentional? Because if it is, I’d like to ask for the same behavior with the LegacyChatService to carry over to the TextChatService.
When do you think this will be out? So I know if I should code everything for already released / upcoming games.
I mean Public Release.
And more importantly, maintaining customizability. To be able to enable/disable a property that would control this behavior. That way, say some developers don’t want that, then they should be able to disable it.
Edit: Yes, I am very passionate about chat. Getting chat tags and chat colors into the chat in 2017 was important to me so now I’m just tryna make sure the new chat is also good quality
I know this is not a very big issue, but can you guys make the coloring consistent with the leaderboard? Leaderboard uses 31, 33, 35 while chat uses 0, 0, 0, and it looks kinda bad
I have a 1 suggestion.
Can you make it work with adding tag / colours with using a function? I tried the other day but my studio kept crashing like instantly closing the studio with no warning that might be because I edited the script wrong that I might need to learn but I just wanted to put this here in case you never supported it.
I can’t seem to get the crashing happening again I guess that’s a good thing for now right?
Hello.
Actually it’s a very nice update ! We will be able to get a new interface for chatting that is futurist, including good add-ons like color text, commands and tags ! It’s a very nice upcoming update. Also just a little suggestion for the chat. Can you add two things, one that could preview our messages so we can see things that is innapropriate and so correct them and another one where in Roblox Options, you can choose a chat color, so your name will be displayed with your favourite color. Else it’s a very good update and I hope that it will deploy in the very soon future !
Sincerely,
Vikko151.
I’m pretty sure that the new UI is experimental and you can only use it in studio.
Its in beta, so it doesnt work in live servers
This looks great so far an I’m excited to use it! The current chat system is very buggy, for example, it throws an error if a speaker to a text channel is removed while they have the tab of the channel open on their screen, so I had to fork the entire script just to erase the line that throws an error. Also, my custom text channel system allows players to create the names of their channels, so I had to figure out a unique way to make sure two channels don’t have the same name, since channels are strings and not instances. I hope little things like this are fixed in the new system.