New In-Experience Text Chat System Public Release!

Updates Announcements
, ,
#270

Modify the PrefixText on the TextSource.

#271

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
#272

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:

  1. Channel tabs are non-existent.
  2. Inability to use TextChannel:DisplaySystemMessage() from the server.
  3. Inability to have a non-player speaker, thus the inability to send messages from the server.
  4. No documentation on how to create a chat channel. I had to figure it out on my own.
  5. 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
#273

This is definitely my biggest gripe with it. I don’t understand why we can’t do this.

4 Likes
#274

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
#275

TextChatService Recent Bug Report

  • ‘/’ Chat Box Input
    Currently, whenever a PC player uses the ‘/’ shortcut to open the chatbox and begin typing, the ‘/’ is also inputted when it shouldn’t be.

  • Bubble Chat
    Bubble chat has also been affected by switching to TextChatService.

  1. Animations are not functioning as expected. When the last chat bubble disappears, it doesn’t smoothly fade out like the rest.
  2. I’ve received many reports of chat bubbles disappearing too quickly (within a second of being sent) for players or not showing up at all. This is extremely damaging to my game and should be looked into immediately.
  3. Using ‘game:GetService(“Chat”):Chat()’ for NPCs is also buggy too. I’ve had many reports of these chat bubbles not showing up at all for players.
    Although this isn’t all the time.

Everyone using TextChatService really needs these issues to be looked into. I’ve been sending in reports (although I don’t have access to #bug-reports yet) and have waited months for these issues to be fixed, and they haven’t.

8 Likes
New TextChatService "/" to send message sends slash in message
#276

This needs more attention. I am tired of bugs being introduced to the chat system on a weekly basis, and I can do nothing about it. The slash (/) bug is particularly annoying.

Another bug has also been introduced where two colons (:), with the same color as the player’s name, appear after a player
's name in the chat after someone has chatted (it is only supposed to be one colon, colored white)

Example: Player:: Hello, world!

There should also be an option to disable the voice chat bubble that constantly stays over your head. An active icon located at the top left of the screen, where most of the Roblox core features are located, would suffice.

7 Likes
#277

Hi, this should be fixed now, are you still running into this issue?

3 Likes
#278

Hi, a fix for this was rolled out some time ago, are you still running into this issue?

3 Likes
#279

We’ve recently updated our docs and tutorial to contain more information regarding TextChannels, are there any more documentation you’d like to see regarding TextChatService?

3 Likes
#280

Are you still running into this issue?

3 Likes
#281

Since system messages are sent within the context of the receiving client, is there a reason why selectively sending system messages is not sufficient as opposed to trying to retroactively filter already sent system messages?

3 Likes
#282

Regarding RegisterProcessCommandsFunction:

For your particular example:

forcefield/all|message/“I’m about to explode”|explode/me|message/“Phew, I had forcefield!” …

considering its very unique, overloading nature I recommend using OnIncomingMessage to parse the string, or create a separate TextBox for strings like this and use SendAsync to send the actual string message to the appropriate channels. I understand the increase in complexity but one of the reasons the architecture has been streamlined like this is to clarify pipelines between sending messages and binding commands.
For example, if a user reported a particular message and we had to evaluate "forcefield/all|message/“I’m about to explode”|explode/me|message/“Phew, I had forcefield! …”, understandably this would not be the most comprehensive message to evaluate/moderate especially when we’re trying to understand the context. We wouldn’t be immediately aware what string was actually rendered to the client and what was the command, because of its very unique syntax.
→ We can only process 1 command at a time.
We’ve chosen to approach with a simpler, easier-to-use architecture prevalent in many messaging systems (messaging apps, some in-game chat systems in other games, etc).
→ We require a new instance for every single command: this doesn’t seem like an improvement.
This is consistent with the architecture from above and for code sanity it may be best to bind the same callback to the various Instances (consider the instances as containers holding just the aliases). For example, in the Triggered event you can have a function called “ProcessAllCommands” and you can have all the events call this single command and have a single function that processes all instances. This way you have all the aliases visible in the Explorer while from the code there is a single switch-like processing place for all commands.
→ We can only have 2 alias per command - why so restrictive?
Are there any notable examples of 2+ aliases per command commonly used in other instances? We’d love to take a look at them and see how that may fit into the current architecture. In addition, how would 2+ aliases be bound in a Studio/Explorer/Properties panel friendly way? Strings separated by commas? Tables? We’d love to hear any feedback as this was a major design consideration for us as we tried to prioritize ease of use and simplicity to bring accessible development while trying to balance customizability.

We understand you have a very rare and unique command overloading system and recommend some of the other approach described above. We’re aiming to maintain the integrity of messages sent from clients to the server, so we want any modifications to the actual messages being sent and shown to other clients to be explicit and intentional from a developer’s perspective for the sake of the safety of users (ex: a user typing “hello” and developer code parsing this and sending a different message that includes profanity, then we know it’s by the act of a malicious developer as opposed to a bad user).

If you have any additional questions, please post on TextChatService is now the default for new experiences!, which is being more actively monitored for feedback. Thank you.

1 Like
#283

Hi, with respect to some of your points:

  1. Channel tabs are non-existent.
    We’re continuing our development on this and are currently finalizing UI/UX for the tabs with consideration for some of our other future features for the in-experience chat UI and TextChatService.
  2. Inability to use TextChannel:DisplaySystemMessage() from the server.
    We introduced this architecture so developers can be explicit with messages sent to each client. As you are well aware, Roblox has to accommodate a wide range of users needing to follow a variety of set of policies (which is why we offer TextService:FilterStringAsync and PolicyService to better serve appropriate policy-abiding content to all of your users). For example, a particular system message might be okay for a certain age group but not okay for another, younger group. If we made this function server-sided then it is more likely messages may be not appropriately served to users while considering different policies. I understand the increase in complexity from the developer’s perspective (as you need to add a RemoteEvent to trigger DisplaySystemMessage on the client from the server) but we brought this architecture to encourage better practices of user-specific and appropriate messages (and also to consider other needs such as user-region specific, localized system messages, of which processing would ideally be done on the client-side based on each client’s needs).
  3. Inability to have a non-player speaker, thus the inability to send messages from the server.
    We’re currently working on a more formal, streamlined set of APIs to better accommodate this need. Thank you for your patience as we continue to work on this.
  4. No documentation on how to create a chat channel. I had to figure it out on my own.
    We’re planning on working on a separate TextChannel usage article when channel tab work is finished, although we did recently add more higher-level documentation for TextChatService as well: In-Experience Text Chat System | Roblox Creator Documentation.
  5. Inferior command processing system which will require major rework on my part.
    Please read my response to a similar feedback here: New In-Experience Text Chat System Public Release! - #282 by SubtleShuttle

If you have any additional questions, please post on TextChatService is now the default for new experiences!, which is being more actively monitored for feedback. Thank you.

1 Like
Allow TextChannel:DisplaySystemMessage() to be used from the server
TextChatService is now the default for new experiences!
#284

Please check my recent responses, but if you have any other feedback please post on TextChatService is now the default for new experiences!, which is being more actively monitored for feedback. Thank you.

2 Likes
#285
1 Like
TextChatService is now the default for new experiences!
#286

For the colon issue, are you changing anything about the PrefixText and/or modifying the message through our modifying API? Also, is this for legacy chat or TextChatService?

#287

Thanks. Do I need to repost what I’ve said here or has it been noted down already?

1 Like
#288

Considering the scattered nature of the replies you’ve decentralized in various posts, coupled with the time that has passed since some of your feedback, I think it would be best if you can consolidate some of your most relevant replies in the linked post for clarity!

#289

This happens when using TextChatService. I am modifying the message, but only for prepending a tag.

1 Like