That looks really cool! It would look even cooler in my group’s hangout!
Github link not works probably you forgot at private
Edit: Great job btw
Sorry about that! Fixed ahaha.
Thanks a lot! Until the documentation is released, I’ll definitely be experimenting with this.
I am working on an improved version (also renamed) that will be easier to configure and will have a small optimization. Plus it will allow for future updates by switching to a variety handler system for incoming messages, dependent on if it’s a player, system message, and so on.
Update 1.1.0
Changes
- Renamed to TextChatService+ (I have to admit inspiration from TextChat+)
- Reorganized the modules within the script
- Created system message handler
- Created global configuration options
- More configuration options for prefixes, name colors, and chat colors
- Minor optimizations
- Easier support for future updates
Bug Fixes
- The entire script was a bug
Demonstration Video
This video is a mess. I am sorry you have to witness this. I am just a programmer; I don’t do marketing. aaaaaaaaaaaaa sorry.
Hi, I have a question. Is there support for UiGradients for chat tag & name color? If not, could you add support for it?
I will definitely include that in the next update!
Nevermind. I just realized I there is no gradient option for rich text and I can’t add a UIGradient object to the prefix text label because Roblox doesn’t expose that to developers
This looks really cool, hoping to use it in my new game!
Damn nice name wonder where that came from
You bet, that’s a nice source.
Cool.
Few things:
- Does this not support multiple prefixes?
- For the client (only) there’s a 1s delay applying the actual colour and prefix to the message, is that just me?
-
It does not, at this moment, no. I may add that in the future if Roblox intends to continue support for this new chat system (they have not made any updates in a while).
-
This is not just you. Unfortunately, Roblox shows the message before extra data has been calculated and added in order to make it “feel responsive” (their words) however that makes it look really ugly when applying prefixes and such. In the legacy Roblox chat, it applied everything BEFORE making the message visible. More information can be found in this post New Beta In-Experience Chat System for Channels, Filtering and More! - #155 by be_nj
Could you calculate the prefixes before the chat message is sent? Like when the player joins the game or a text channel? Yielding within OnIncomingMessage is supported but not ideal since it will delay the rendering of the message arbitrarily.
I could try that, yes. The only reason I didn’t is to recalculate if someone gets a badge, buys a gamepass, joins a group (although this is cached weirdly anyway on Roblox’s end).
The more optimal way would be to do it once and leave it, much like the legacy Roblox chat does with ExtraData.
I may do it for this reason + performance reasons (recalculating after every message is a bit ehh).
I believe do have a cache though that it won’t “recalculate” the game passes, badges, and group for 30 seconds at a time.
You could save your “ExtraData” as attributes on the TextSource or Player object. When the player connects you could write to asset ownership and group membership as attributes and update these attributes if needed during the game session.
Your OnIncomingMessage hooks would simply read from these attributes.
We recommend this because if this information is important enough to show before each chat message, it likely has some tangible gameplay implications as well, and confining that information in a chat&specific context would not let you easily reuse that information (it would have to be stored external if chat anyway)
I do like that. I may rewrite the script then for those performance optimizations. This version was written very hastily and didn’t really have much care put into it, to be honest.
Update 1.2.0
Changes
- Cached “ExtraData” when player joins, when team updates, when attribute updates, when they are added/removed from a CollectionService tag, or every 10 seconds (by default)
- Minor optimizations for performance; messages now show very quickly.
I briefly looked over your github repository and noticed you have a different code path for Sending and Success messages:
Shouldnt your sending handler also read the attributes like the Success one? I think that may be the artifacting that you’re seeing.