Also there also seems to be an issue with the chat bubbles that doesn’t happen all of the time, potentially fixing itself after a certain amount of time in-server?
The transition for the chat fading away is causing it to turn into a bunch of circles for some reason. In this example we are using ImageLabels and UICorner (without UICorner, the ImageLabels with text when displaying the bubble become circular as seen in the fading transition, so we can’t remove this)
Alright, so the documentation for this new system doesn’t seem to be very descriptive for what I’m looking for. My games don’t customize the chat system, they just add NPC chatter, both in the chat window and as bubble chat. How do I go about doing that with this new system? This is a game-breaking change for several projects of mine that rely on the existing chat stuff for notifications of important game events.
I recall asking about this on Discord a few weeks ago and being told that the relevant functions are now clientside rather than serverside (cool, but I have no use for restricting them to only some clients, personally)… and I can’t find them.
Is there any possible way to make a server-side secure Proximity chat system with this? I know I can put filters on the client for the distance of the player who sent the message, but this can easily be bypassed by an exploiter.
With the old system, I was able to do these checks on the server and only send the proximity messages to players who met the criteria (I would use :GetChatForUserAsync() to filter messages on the server). The TextChannel works great for more static communication, like for players on the same team, but for anything highly dynamic like a proximity chat I am struggling to find a good solution for.
Please let me know if you guys have any ideas!
Set players’ TextSource property CanSend to false, establish remote events for sending system announcements to the players (TextChannel:DisplaySystemMessage()), then use that for sending player messages to the targets who are in the real proximity by using RemoteEvent:FireClient().
You can use TextChannel.ShouldDeliverCallback on the server to conditionally deliver messages.
If you’re not using a custom TextChannel, you should wait for the RBXGeneral channel to be loaded (TextChatService.TextChannels.RBXGeneral) before setting the callback.
theres a bug where the message gets mixed with the username or doesnt get displayed at all
(it seems to happen with long display names)
TextChatService is still very buggy for being a replacment to legacy text chat.
the symbols < and > show up as < and > in the chat if u do /w for some reason instead of their actual symbols in the TextChatService
I am wondering, if any experience is not migrated to the new chat service by April, will creators have a choice to have their experience not auto-migrate to the new chat system?
Many games will break, would the chat just be disabled in non-updated experiences?
Thank you.
The new chat system does not display players chats history that were sent before you join a game. Will this be brought back?
I agree. It’s also a lot tiner and harder for my eyes to see people’s chat. I have ot use bloxstrap to increase the text size, which ends up brekaing the whole thing and caUSING TEXT TO BE BLOCKED BY other’s chats. (sorry for capsd lock)
Hey, I recently had my game get automatically converted to the new chat system (which I thought until I had until April to do) and now after I have converted to the new system, ChatService:FilterStringAsync and textservice:FilterStringAsync both continue to always return as blank strings. How do I fix this, now that I have converted? It appears that changing between LegacyChatService and TextChatService has no impact on this behavior. The broadcast chat functions appear to function as intended.
Text code:
local p=game:GetService(“Players”):children()[1]
chat=game:GetService(“Chat”)
textserv=game:GetService(“TextService”)
warn(textserv:FilterStringAsync(“TEST”,p.UserId):GetChatForUserAsync(p.UserId))
warn(textserv:FilterStringAsync(“TEST”,p.UserId):GetNonChatStringForBroadcastAsync())
warn(chat:FilterStringAsync(“TEST”,p,p))
warn(chat:FilterStringForBroadcast(“TEST”,p))
game: TJW's Admin House - Roblox
Edit: Additional question: Do we need to convert our chatservice:FilterStringAsync to textservice:FilterStringAsync? What about in cases such as if 1. a player is seeing their own message and 2. if whether or not two players can commuicate has been checked by CanUsersDirectChatAsync?
Goodness, another headache to wake up to.
This seems like a promising system to work with, except the fact that the documentation provided is as scarce as pneumonia’s documentation before 1945. Hopefully results don’t have to be produced with similar protocol, but crude humor aside: why is there absolutely no coverage on such a game-changing update (and by “no” “coverage” I also mean every doc page seems half-baked and either doesn’t show results or doesn’t contextualize concepts, ex. “use isVIP attribute!!” ok, how the hell do I make that?!)???
I have been scouring the internet hours-on for ways to re-replicate my old systems such as a simple join/leaving message to the entire server, though all I can ever seem to come across is local text, with none of my tests reaping any success thus far. It is seriously infuriating when an entire community of people are left to pick up after corporations and figure things out on their own.
Anyway, if anybody has any community-curated information on how to do such menial tasks, it would be immensely appreciated. God bless the nerds!
Our game was just force migrated, breaking all new servers. Our game is definitely still not ready, we got no warning, and there appears to be no setting to revert this.
I don’t know much about your system, but I know how to make join and leave messages work and many other chat related things.
Here how to make join / leave work on entire server (messages are seen on all players in server).
I recommend using these scripts in a baseplate so no interferences.
Script in ServerScriptService:
local Players = game:GetService('Players')
local ReplicatedStorage = game:GetService('ReplicatedStorage')
-- Lets create a remote event cause we need to connect to players
local PlayerGameStatusMessage = Instance.new('RemoteEvent')
PlayerGameStatusMessage.Name = 'PlayerGameStatusMessage'
PlayerGameStatusMessage.Parent = ReplicatedStorage
Players.PlayerAdded:Connect(function(Player)
task.wait(.25) -- let the player that just join load their chat script
PlayerGameStatusMessage:FireAllClients(Player, 'joined')
end)
Players.PlayerRemoving:Connect(function(Player)
PlayerGameStatusMessage:FireAllClients(Player, 'left')
end)
Local script in Starter Player scripts:
local TextChatService = game:GetService('TextChatService')
local SystemChat: TextChannel = TextChatService:WaitForChild('TextChannels'):WaitForChild('RBXSystem')
local ClientJoined = workspace:GetServerTimeNow()
-- Will Display a message in chat to local user in 'RBXSystem' channel
local function DisplayMessage(Message: string)
local function Show()
SystemChat:DisplaySystemMessage(Message)
end
if 1 < time() - ClientJoined then
Show() -- Chat is loaded
else
-- Oh no! Chat gui has not loaded. We need to wait a second to make sure it is loaded.
coroutine.wrap(function()
task.wait(1 - (workspace:GetServerTimeNow() - ClientJoined))
Show()
end)()
end
end
--Makes Text turn the color you want.
function ColorText(Text: string, Color: Color3): string
return `<font color="#{Color:ToHex()}">{Text}</font>`
end
-- Player Join/leave message in chat
local ReplicatedStorage = game:GetService('ReplicatedStorage')
local PlayerGameStatusMessage: RemoteEvent = ReplicatedStorage:WaitForChild('PlayerGameStatusMessage')
PlayerGameStatusMessage.OnClientEvent:Connect(function(SentPlayer: Player, Status: 'joined' | 'left')
-- Lets make the '[Server]: ' part of the message blue!
local ServerText = ColorText('[Server]: ', Color3.new(0.329412, 0.47451, 1))
-- Green for joined game, Red for left game
local StatusColor = (Status == 'joined' and Color3.new(0.364706, 1, 0.254902)) or Color3.new(1, 0.494118, 0.501961)
DisplayMessage(`{ServerText}{SentPlayer.DisplayName} has {ColorText(Status, StatusColor)} the game.`)
end)
Results:
You unfortunately can no longer get the server to create the messages but you can use remote events and make the server tell the clients what to show. I’m guessing this change is made so the server is not the one using resources to make messages.
I hope this helps, if there are any other things I can help with then reply to this message.
There shouldn’t even be a need for a server script in this case. The client could just listen to those events themselves and send the system message.
True, but mostly wanted to show how the server no longer plays a huge role in messages but instead has to use remote events. A server side example would be displaying a message like “Red team has won!” by using a remote event server side to send to clients. Remote events for messages will be handy for any beginners reading this.
Yeah getting into this now and seeing that there seems to be no proper way to retain chat history… its crushing the inner dev-soul in me.
I made an open source implementation of TextChatService that includes a ChatTextFaded and ChatBackgroundFaded property you can hook onto via GetPropertyChangedSignal. You can learn more about it here OpenTextChatService - Open-Source Implementation of TextChatService. It is a faithful recreation of the default TextChatService UI so you won’t notice any difference, but everything is handled and rendered by the developer. I think this should solve your problem. 
local TextChatService = require(pathToOpenTextChatService)
TextChatService:GetPropertyChangedSignal("ChatBackgroundFaded"):Connect(function()
print(`Chatbox visible: {TextChatService.ChatBackgroundFaded}`)
end)
--Alternatively
TextChatService:GetPropertyChangedSignal("ChatBackgroundTransparency"):Connect(function()
print(`Chatbox transparency: {TextChatService.ChatBackgroundTransparency}`)
end)
I am bumping my original reply to update it with new information. The first few paragraphs are just feedback.
My game was automatically migrated on March 17th to TextChatService despite having :CanUsersDirectChatAsync() implemented in December of last year. My implementation prevented whisper chat and private messages in the game from being sent without first passing this check, which is what I thought was the requirement to meet by the January 30th deadline.
This broke my game, which I quickly fixed because I saw the email about automatic conversion (note: the actual conversion seemed to occur a couple days after the email was sent, and I couldn’t find any direct messaging systems requiring :CanUsersDirectChatAsync() that I missed), but I have no way of restoring chat filter functionality without using :FilterStringForBroadcast()-related filters, which are strong enough that they prevent communication of things such as gear IDs in logs, and I’m not even sure if they’re supposed to be permittable for player-to-player messages.
The only idea I might have about detection of the :CanUsersDirectChatAsync() implementation in my case would be if games using :GetChatForUserAsync for announcer-to-recipient or moderator-to-recipient announcement messages can trigger detection. If this is the case, then I have a few questions about what-if cases, especially in terms of what needs to be done for sandbox games with announcements, event-hosting games, and in-game moderation.
I also never received the original email about changes being needed for compliance for this experience, although I was given the same email for another experience.
After contacting support and going through some back and forth, I ended up at a message that I essentially took as saying that support can’t help every single experience (not 100% sure they understand the issue is something I have no control over, but based on the forwarding at least some of them do). I have now asked it be treated as a bug report if there’s no way that their team can help with flipping a flag like this (I tried to acknowledge that there could’ve been a :CanUsersDirectChatAsync()-needing thing I could’ve missed).
–
It would be extremely beneficial if there was an appeal process to have the “No-opt” flag for TextFilterResult:GetChatForUserAsync lifted for experiences. Without such help, I may have to move my game to another experience ID, causing all my users to lose save data. Other games that are not regularly updated will gradually run into this the next time they try to update their experiences. The “compatability mode” itself is still appreciated as an alternative to simply moderating the games.
@be_nj (Mentioning in hope of the appropriate team seeing this)