New In-Experience Text Chat System Public Release!

Are you still running into this issue?

3 Likes

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

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

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

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
1 Like

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?

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

1 Like

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!

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

1 Like

I am no longer running into this issue, however, you might know already that on pc if you press ‘/’ it will also type that in the chat.

It’s nice to see some improvement, on roblox UI. But please update the settings tap, it looks outdated compared to everything else.

When making a new message with the “/” key, it gets added into the chat message. This has never happened with the old chat system, and i’m wondering if there is a way to fix that? There should be a video attached that shows the problem.

2 Likes

No, but all of my players are experience a bug where when they press “/” once, their message starts with /

2 Likes

This issue is still occurring in my games

1 Like

Can we add gradients to the text, please

1 Like

how do I change this I do not want this for my game

4 Likes

It’s been 1 year. Whats the status?

Hi! We’ve started work on this last week! Stay tuned for more announcements in the coming few months!

5 Likes

How can you disable the Gui in this moments?

1 Like