I would really like to customize what the target channel chip for our own TextChannels say. Because I think it would be important to let the player know which channel they are speaking in, even if it’s in our own custom TextChannel
Sometimes, multi-line chats (Both code-generated and player-generated) will not make the chat scroll down even if it’s already at the bottom prior to the message. This results in the player constantly having to scroll down to make sure they’re viewing the most up-to-date messages. Does anyone know how I could potentially fix this issue?
I can not seem to access the raw gui elements this service uses, and cannot manipulate any of the scrolling elements to fix it myself it seems. I have already built a lot of my system around this new service, and it would be a shame to scrap everything due to something like this.
I am also having this exact same issue, what’s worse is that I can’t figure out how to access the raw gui to even fix it myself, assuming there’s even a method for that.
Hi, we’re currently in the process of rolling out a fix for this issue!
1 Like
That’s a relief, hopefully it’s soon! I have a deadline hounding for my neck 
Sounds interesting, maybe I should try it someday
Docs and Tutorials are not that good about how to use a text channel.
1 Like
I am also having this exact same issue, players have to scroll down to make sure they’re viewing the most up-to-date messages.
1 Like
I also have a question, if I wanted to make something similar to /t /team to talk to players without having teams but a variable stored inside a player, how would I approach this?
can we please get more ui control, getting gradients on chat tags is now impossible since the ui is under coregui
Ive also been trying to make colored system messages, but that is also impossible with the current controls
Both of these were possible in the old version with a super simple edit, but are gone here
2 Likes
I would also like the ability to modify the chat gui, that in itself gave a lot of room for modification which is only limited by the new system.
3 Likes
Is there an official way to listen to system messages from the RBXSystem TextChannel and prevent them from being send/received? It seems that the TextChannel.ShouldDeliverCallback doesn’t work for system messages because there’s no source for the message. So the only way that I’ve found to bypass this is by using TextChatService.OnIncomingMessage and returning something else other than TextChatMessageProperties to this callback when the channel where the message was received is RBXSystem, but it spams the output with this [1] message, which although not breaking anything it’s really unwanted to occur.
[1]
1 Like
I am also curious about this, it seems to not be present functionality.
Hi
Is there any update on the channel tabs? It seems this isn’t yet supported.
EDIT: There also seems to be a bug where the chat history sometimes doesn’t show when a player (re)joins the game.
Is there a way to change a sender’s username so I can hide a player’s identity?
Modify the PrefixText on the TextSource.
The way that chat commands are currently setup makes them vastly inferior to legacy methods and makes it effectively impossible to us to upgrade to the new text service. @SubtleShuttle
For server-side chat modules we used to be able to connect to RegisterProcessCommandsFunction to process any and all of our command logic.
We used this to fire a function of our own with valuable data provided by the legacy system, such as the speaker’s name and the message, to process what admin command(s) we wanted to fire.
For example, on legacy, we would be able to chain our commands as follows:
forcefield/all|message/“I’m about to explode”|explode/me|message/“Phew, I had forcefield!” …
As far as I can tell by documentation there’s no longer any way for us to parse full length chat messages on the server and tell which player sent this message with the new system.
The new TextChatCommand seems to be the only way to make a proper chat driven admin system, but it is extremely limitting to us for following reasons;
→ We can only process 1 command at a time.
→ We require a new instance for every single command: this doesn’t seem like an improvement.
→ We can only have 2 alias per command - why so restrictive?
If I want to have 6 alias; which isn’t too far fetched from reality for some commands; I’d currently need to make 3 instances of a TextChatCommand with given alias that’d execute the command.
I can understand how TextChatCommands makes life easier for inexperienced developers whom are looking to create a handful of simple commands, but it’s not very supportive of a fully fledged admin system.
The new system imposes difficult technical hurdles for something as functionally simple as parsing someone’s full length chat message.
Please provide a way for us to parse any full length message, including a reference to the speaker of said message, to more easily transition to the new TextChatService.
1 Like
In checking out the new TextChatService and what it offers, I have found it to be inferior to the legacy chat system. Here’s a list of issues that I have found thus far:
- Channel tabs are non-existent.
- Inability to use
TextChannel:DisplaySystemMessage()from the server. - Inability to have a non-player speaker, thus the inability to send messages from the server.
- No documentation on how to create a chat channel. I had to figure it out on my own.
- Inferior command processing system which will require major rework on my part.
Issues #1 and #4 I can live with. But issues #2, #3, and #5 are a show stopper. Especially #2 and #3 because my game relies on that functionality to create an immersive environment. By moving the display of system messages to the client, I now have to create a new remote event along with new client scripts to display system messages to the players when before I could just do it from the server and not worry about it.
For #3, I have announcements that depict what is going on in the game. Those are non-player speakers which I cannot use in the new system. Yes, I tried it. If I give a UserId of -1, it returns nil for the TextSource which causes an error. With the legacy chat system, when I send a message using a speaker, that message gets displayed on all channels that that speaker is on.
Issue 5 has the property that the way that commands are initiated is incompatible with my command system. In order to make it compatible, major rework of my command system framework code will be required. Furthermore, the way that it is implemented is weird to say the least. Using a Triggered event against the TextChatCommand instance is a good idea on paper, but it is lousy in implementation. By using ChatService:RegisterProcessCommandsFunction, I can have parsing, analysis, and processing centralized. This new system decentralizes the processing which makes coding command more difficult for me. My command system is highly modular and I use my own parser. By performing the initial parsing for us, we lose some control. The big one that I have seen mentioned is the fact that the new system is case sensitive whereas the old system you could have case-insensitive commands.
This is not ready for prime time and I for one, will not be migrating to the new system until these issues are corrected, especially #2 and #3.
3 Likes
This is definitely my biggest gripe with it. I don’t understand why we can’t do this.
4 Likes
I don’t know either, but I know it can be done because Roblox’s own code does it. They way they implemented this makes me question the logic behind the design decisions that they made when laying out the architecture.
I don’t understand why we have to make our own chat remotes to have the functionality in the new system that the legacy system provides out of the box. At this point, it almost makes sense for me to develop my own chat system and kick Roblox’s system out the door because it’s useless. The only problem with doing that is that I’m not sure if I can guarantee that I can filter the messages according to Roblox’s policy.
I know for a fact that eventually we will all be forced to use the new chat system. But now I think it’s time to send a feature request to @bug-support to let someone know about these problems. Don’t hold your breath though, how long has it been since they said that they were going to implement tabs and we are still waiting for it.
I do not know how many active developers have migrated to the new system already, but in my opinion, it’s a downgrade instead of an upgrade. Oh it looks nice, but I favor functionality over aesthetics.
5 Likes