I made a feature request a while back regarding this, it would be great to have it looked at!
3 Likes
Why can’t this be implemented by default? It’s a genuinely useful feature that helps you understand who’s talking at a glance.
2 Likes
I also agree a feature like ChatWindowPosition would be useful!
But “huge deterrent for some if not most experiences that have a huge following base” seems like a pretty strong statement.
Instead of making a conjecture against a conjecture, I decided to check out the top 25 experiences in this list (Discover - Roblox) at the time of writing.
Now that top 25 sampling is also not complete either, but I felt that’s a bit more substantial than making a claim like “most experiences that have a huge following base” without too much support.
| Rank | Name | Position |
|---|---|---|
| 1 | Blox Fruits | TL |
| 2 | Anime Fighters Simulator | TL |
| 3 | Brookhaven RP | TL |
| 4 | Grand Piece Online | TL |
| 5 | Mining Simulator | TL |
| 6 | Shindo Life | TL |
| 7 | Welcome to Bloxburg | TL |
| 8 | Adopt Me! | TL |
| 9 | Your Bizarre Adventure | BL |
| 10 | Murder Mystery 2 | TL |
| 11 | Anime Battle Arena | TL |
| 12 | Da Hood | TL |
| 13 | BedWars | TL |
| 14 | Clicker Simulator | TL |
| 15 | Royale High | TL |
| 16 | All Star Tower Defense | TL |
| 17 | Weapon Fighting Simulator | TL |
| 18 | Bee Swam Simulator | TR |
| 19 | Pet Simulator X | TL |
| 20 | Jailbreak | TL |
| 21 | Phantom Forces | BL |
| 22 | Apeirophobia | TL |
| 23 | Goal Kick Simulator | TL |
| 24 | King Legacy | CL |
| 25 | PLS DONATE | TL |
As you can see 4 games have chat positioned in locations other than top left (TL).
I don’t want to downgrade the importance of ChatWindowPosition like feature (I’d love to have that as well!) but I feel like as a forum member I do have a social responsibility to point out extreme arguments and encourage more data/evidence-driven arguments (as incomplete as my sampling may be though, I think it’s a bit better than nothing).
If you have more substantial supporting data though, I (and probably some other watchers of this topic, perhaps) would love to see it so we can have more constructive conversation!
3 Likes
how does “local Command: TextChatService” work ? and what does “:” do in a script ?
its basically to make sure a value is what it says it is like this
Event.OnClientEvent:Connect(function(Player : Player, Position : Vector3, Value : NumberValue)
end)
1 Like
ohh, tysm, this will help me a lot in my future projects !
A summary of TextChatService Beta changes this week:
- Toggling the top bar chat button off and back on will force the chat window to show like the previous chat.
- Help command lists out command functionality properly
- Fixed a UI lockup when TextChatService.CreateDefaultTextChannels was false
- Chat UI will no longer disappear when respawning your character
- The default RBXGeneral channel will now add the “name chat colors” to the message sender. This will respect the sender’s team color if they are on one as well. This provides an identical experience to the previous chat.
We are planning to release another update next week to reintroduce missing whisper chat functionality. Expect a public post-beta release shortly after. 
11 Likes
Although I’ve only now gotten to poke around with TextChatService, the most immediate gripe I have is that TextSource, the object intended to replace ChatSpeakers, cannot be created by developers. The ability to establish sources divorced from a client is immensely important for representing messages in the chat bar by NPCs or announcements in a convenient location. I commonly use chat systems to deliver announcements either through separate channels or a general chat channel.
The flexibility of the Lua Chat System is precisely why I was initially scared for Roblox to suddenly decide to peel back what was almost a fully supported Lua port of the chat system right back into CoreScripts and just expose customisation. Customisation abilities on these kinds of things often come shallow. I may want all the functionality of TextChatService without using any of the Roblox styling. A huge loss is orienting TextChatService to player-communication only.
Please consider the direction of TextChatService going forward to be able to arbitrarily support any speakers the developer creates in addition to players. Although it is a service intended for chatting with others it should not be restricted solely to player-player communication as we have other use cases for sending messages in chat such as the aforementioned global/server announcements example. TextChatService still does not adequately cover the vast amount of functional customisation that is provided by the Lua Chat System - it remains inferior.
5 Likes
TextChatService can’t do a number of things the Lua Chat System can which make me highly resistant to want to switch. Developer case studies (modifications of the chat system, various ways of using chat) as well as review of the chat team’s own work on the Lua Chat System would go a long way to having the TextChatService hold parity to the former and the vast use cases it can cover.
-
Instance count: The number of instances looks somewhat awful. I’m mostly talking about the fact that the same TextSource (e.g. my TextSource of “colbert2677”) can exist under multiple TextChannels. This is sort of a nitpick: compare the Lua Chat System that only stores a ChatSpeaker object and you can handle per-channel configurations on it with existing API. Only one object.
-
No remove equivalent to AddUserAsync: What do I do here, destroy the TextSource?
-
Can’t preemptively stop messages from being sent: ChatMessage has a hidden property called ShouldDeliver which, if true, will stop the message from being sent at all. I don’t see where I can do that with TextChatService. Additionally, in channels where a player’s TextSource has CanSend false, their message shows for a frame or two before being removed over not sending at all.
- Can’t build features built around conditional sending: I have at least one experience that modifies the Lua Chat System for proximity chat. The chat window is retained however chat messages from entities beyond a certain distance are not rendered in the chat window. This way we can allow players to view chat history of entities nearby via the window but still enforce proximity. Bubble chat would be inadequate on its own because players would have no access to message history.
-
No support for non-player TextSources: I’ve expressed this in two posts of mine, both the first reply to the thread and above. I use non-player ChatSpeakers in my experiences so that NPCs with dialogue can have their messages repeated in the chat window and for convenient announcement space (system messages would work… if they couldn’t be confused for new lines of a previous message or supported extra data).
-
No support for server messages: TextChannel:SendAsync is client-sided. How do I send messages from the server on behalf of a player or potential future non-player TextSource without it being a system message?
-
Non-table message metadata: Do I use JSON here? Metadata is a string.
-
Lack of customisation: There are several settings that are not present as of right now.
-
Draggable: Allow players to drag the chat window. *Judging from the thread, we should be able to build our own frontends soon, at least.
-
Resizeable: Allow players to resize the chat window. *Judging from the thread, we should be able to build our own frontends soon, at least.
-
Channels Tab: Lua Chat System had a configuration that, if enabled, would show a chat window topbar consisting of channels the player had access to. I am completely unsure of how to change channels or isolate messages by their channels.
-
Text and Colour Settings: Anything from font, size and UI colours. *Judging from the thread, we should be able to build our own frontends soon, at least.
-
Internal behaviours: No, letting Roblox automatically tell me what my size and rate limits should be is not a bonus. I want control over that.
-
This is the extent of feedback I have for now.
8 Likes
Thank you for sharing your detailed feedback. I have spent the last year thinking about this problem space and want to assure that a thorough review of developer case studies and the previous chat system have been conducted.
Our aim is to support every previous use case the old system provided with the new system in the near future. To explain the omissions, the first step is to release the TextChatService at a 1:1 baseline with the previous default experience. We decided to plan this way since it will allow us to iteratively release more features and get detailed feedback and metrics on how and when additional features are used. The use cases you mentioned are on our radar, however the current scope of the initial release was limited to the most common developer case studies (basically the default + “chat tags eg: [VIP]” for users which were overwhelmingly popular).
This process will be an on-going effort. In earnest, the public release will not simply be a “V1” nor will you have to wait long for “V2” features. Instead anticipate features rolling out for TextChatService in the release notes frequently.
We hope to earn your opt-in within the coming months!
To address more specific feedback and questions:
The number of unique instance types in the previous system were surprisingly numerous (I counted 11 here, but there are technically more “private” classes that would be modified by our users).
Though this response is more concerned about the multiple TextSources for a given user – we decided to indicate TextChannel enrollment in this manner to make it clear to developers the number of participants in a channel. You may still edit TextSources on a per-channel basis using the Attributes API if needed. Likewise, if you wish to have a single object to reference for each TextSource, you may do so with the Player object itself. We determined this offered the most flexibility for developers regardless of their usecases.
There has been some confusion around this point, but the short answer is: yes, you can simply call TextSource:Destroy() to remove a user from a TextChannel.
We’ve determined a few usecases we’d like to support with this bullet point. A common usecase developers would work around with the previous chat system was to disable default system messages. We feel that we can solve this usecase and the usecase you provided (proximity chat) in a similar manner in the near future.
We intentionally designed TextSources so they may be sourced from an actual user (in server or in another server(!)) or potentially some other source (such as a chat bot or NPC). Unfortunately this was not in scope for our beta and while there are workarounds (such as leveraging DisplaySystemMessage for local chat bots) we have not forgotten this API surface area.
On a similar note, server messages are tricky – how do you localize a server message for 20+ different users? At the moment, we’ve prevented TextChannel:SendAsync from being invoked from the server and instead recommend you use a RemoteEvent to have your clients invoke TextChannel:DisplaySystemMessage with your localized formatted message. However, as we explore the NPC-chat space we may be able to open this up to support authentic “server messages”.
Allowing string or tables for TextChatMessage.Metadata is something we are considering.
In the meantime, we use the Metadata field for default system messages (such as “Your friend has joined the server!”) to allow developers to identify at format these system messages (since they will be localized for the user).
For example:
Message: "Your friend has joined the server!"
Metadata: Roblox.Notification.Friend.Joined
All default system messages will start with “Roblox”. However you may use the metadata field however you’d like. If you want to store information using JSON or some other serialized format, go for it!
Post-public release, our next initiative is to open up customization options for the default chat experience. However, we submit that we are not able to realistically provide every customization option that every experience will need on our platform. That is why we actively support developers creating their own frontend by listening to events from the TextChatService. (No need to wait for that, you can actually do that now in the Beta by setting ChatInputBarConfiguration.Enabled and ChatWindowConfiguration.Enabled to false!)
7 Likes
Just wanted to add on to @be_nj 's comments and also ask some questions as well!
Conversely, how would the “instance count” look if there were multiple TextChannels under a TextSource (since a user could be in multiple text channels)? Or is the comment here more about not making channels/sources not as Instances? The previous Lua Chat System haphazardly attempted an OOP approach to channels/speakers with little formal structure and parity with what some other parts of Roblox engine does. Or is the comment here more about adding more API (other than using attributes as suggested by @be_nj ? Is the “instance count” concern more about perceived usability/efficiency concerns? Would love some clarity on this! (If you don’t have any further thoughts on this, that’s fine too!)
The process to destroy TextSources is in the documentation here: TextSource | Roblox Creator Documentation, in the first few lines we wrote:
Remove TextSources by calling TextSource.Destroy.
Which part of this was not clear? We’d love some feedback so we can improve our documentation and onboarding experience!
This sounds like a bug we should fix! Thanks for letting us know!
You may have noticed we have ChatWindowConfiguration and ChatInputBarConfiguration! They seem a bit sparse with only an Enabled boolean but this is us setting foundational work for exposing more configurations, from which we’ll take feedback (yours included!) and prioritize work accordingly!
Also noticed this was repeated a few times in the message! Is this a typo or is there something you wanted to say in detail?
Thanks for the feedback!
2 Likes
This is probably more along the lines of what I’m thinking. I think I’m still operating under the preconceived notion that pure Lua objects created by the Lua Chat System were easier to link together because they were more abstract and detached from the DataModel. To me I typically always try to merge state to one object if possible so for me that would’ve entailed one TextSource to represent the player and then a state describing their channel access.
I think the best way to describe “instance count” as a concern here in my eyes is thinking about the presence of instances in the DataModel; and that for really deep modifications of TextChatService there can end up being a lot of instances each with their own connections and memory cost and all. That includes being tied into Roblox pipelines where potentially undesirable (i.e. replication for a config only used by the server/client) by nature of being instances. Roblox is good at keeping these instances low cost though so it’s probably not as much a problem as I think it to be.
Thanks for pointing this out, I did miss this. I was actually looking at the TextChannel API for figuring out how to switch in and out users from the channel so when I only saw an add function I wasn’t really sure what to do or where to look for a remove function.
I think it would be clear if TextChannel also had instructions on how to add and remove sources from channels as part of documentation or (code) examples. When I’m looking up documentation for how to add or remove users to channels the first place I’m going to look is TextChannel because that’s realistically where a TextSource is going to end up. TextSource docs to me would only be relevant if I wanted to modify a source’s state and that’s not my most immediate thought for channel management when I see that sources are added under TextChannels at run time.
Sorry, I actually meant to add a footnote so I wouldn’t have to repeat that. I did want to acknowledge that from the direction of the chat development from the thread it looks like we’ll be able to build our own Guis and thus resolve a couple of the lack of customisation points, though they’d be nice to have if we want to continue using the default look.
Thank you and benjj both very much for the questions and clarification about the chat, its development, investigation and planning. They’ve been very insightful about the road for the future with TextChatService and I look forward to being able to offer more informed feedback if applicable as the service develops and making the switch. Chat is a primary driver of social interaction and information communication for the majority of my experiences so I’m happy to know there’s an end goal to hold parity and/or better from what the Lua Chat System currently offers.
3 Likes
This chat system is still really buggy
I can’t give exact reproduction steps, but toggling the chat has really weird behaviour, sometimes all the chat text fades away, while the box is visible, sometimes the box fades away while I’m typing
2 Likes
Is there a way (like in the legacy chat) to fire an event if the chat bar is focused/is being typed in?
Like this:
The textbox is just called “TextBox”, you could try checking the parent name as well.
EDIT: Doesnt seem like its possible, the event just doesnt fire
2 Likes
Yeah, I tried to print the name of the textbox so I could edit the script, but as you said, the “TextBoxFocused” event doesn’t fire. Thank you for your reply anyway, hopefully this is looked into.
1 Like
Slight problem that affects the user experience:
When using “SetCoreEnabled” to enable and disable the chat, upon re-enabling it, the chat will scroll back up to the top, making the user have to scroll back down.
This is an issue because many games disable the chat while loading/teleporting to an area.
Another issue:
I’m sure this has been mentioned in other replies. The chat sometimes fades out while you’re still typing a message.
Walking issue:
When holding a key (like ‘W’ for walking), and then you open chat, you will remain walking even when you let go of the key. The only way to stop this is by pressing the same key again when you have closed the chat.
Final issue:
When the chat is closed, you cannot press “/” to open it again (like the legacy chat), instead, you have to open it manually from the button. This may not seem like a big issue but muscle memory from opening the chat that way makes it confusing.
4 Likes
We are considering exposing an event or property on ChatInputBarConfiguration for typing within the default textbox. To help prioritize, what are you trying to accomplish with this?
2 Likes
Is this occuring on a desktop or a mobile device?
3 Likes
Haven’t tested mobile, happens on desktop.
1 Like