Recently I’ve been working on a game for a group where I’ve been required to apply some TextChannels to higher ranking members of the group - which I have already programmed to work successfully - but I came across an issue with that being I was unable to completely revoke a user’s access to a TextChannel after having previously granted it via TextChannel:AddUserAsync(): users were still able to see the channel that they were in before being revoked, and the users were still, yes, able to type messages in that channel, however the messages that the user attempted to send in that channel didn’t get through to the other players (see Figure 1 below):
Figure 1: Typing two messages into the chat, then removing the TextSource of the player server-side, then attempting to send another message in the chat.
The case shown above accounted for any channel by default, including the above which shows the most relevant issue about the happening that this is default to players changing teams too and not being able to revoke access to those team-only channels instantly.
The main issue I had with this on my end was that, for this system I’m working on, a part of it includes a Typing Indicator which I have already programmed; the system relies on showing only players who are part of specific channels the typing indicator, and if channels which have been attempted to have been revoked from users’ access are still there, the system still looks at the ChatInputBarConfiguration.TargetTextChannel and sees that the user is typing in that channel, which should not be happening.
I researched on the official Roblox Documentation before messaging here, and found out about TextSources. I noticed on the documentation that where it mentioned how to “Remove TextSources”, the documentation was clearly wrong for the fact that it mentioned that the removal of TextSources was done via “calling TextSource.Destroy” (see Figure 2 below):
I assumed this was incorrect for the fact that it should be done through the usual usage of Instance:Destroy(), and so after taking no chances and naturally having tried to run game.TextChatService.CustomChannels.Staff.GreenTheBlaze.Destroy() (see Figure 3 below), I tried out by running the following into the Developer Console in-game, and also the Command Bar on Studio: game:GetService("TextChatService").CustomChannels.Staff:FindFirstChild("GreenTheBlaze"):Destroy().
Figure 3: The expected erroneous result of having tried to call a method through the incorrect use of the dot operator to call a function.
After having removed the TextSource, as mentioned before, the user could still see the channel but messages again did not go through to the other players who had access to the same channel.
Any help and advice on how I can go about removing access from players to TextChannels would be much appreciated!
Not even just that, and yes that would be useful, but the fact that players when removed from a team are not automatically removed from the previous team chat, that just doesn’t make sense at all…
Roblox does this all the time with new/existing features, where users who have a specific use case aren’t always considered. For this, though, I’d expect it to be considered default functionality.
I do not usually post, but I figured I’d provide a temporary solution until Roblox adds this functionality.
If you go ahead and locally re-parent the TextChannel itself while also destroying the TextSource on the server (as described in figure 2) this will cause the CoreChat to unregister the TextChannel locally as the intended functionality of removing a user from a text channel should do.
In simplified terms:
(SERVER) Destroy the TextSource of the user you want to remove from the specific TextChannel
Another note: Make sure if the user is in the channel at all and viewing it (meaning it MIGHT be their target channel) to reset the target channel using ChatInputBarConfiguration.TargetTextChannel to something other than the specific channel you are removing. It seems to show the channel remnants if you do not do this.
I’m unsure to as why this works, but I’d have to assume the CoreChat removes the channel when it doesn’t exist, and then upon its readdition it has no TextSource matching the client.
Hopefully this helps anyone having the same issue, goodluck.
This is a well-known bug of the TextChannels that has been repeatedly reported. It’s a UI bug with TextChatService and the main way to fix it is to have a custom Chat UI that handles channel sorting and display based on TextSources.
As far as I’m aware, I’ve got a few extra things to handle now too because of a lot of these components of TextChatService seem to be reliant on the Chat UI asserting authority on the state of the UI elements by verifying the TextChannels and TextSources, rather than the objects (TextChannels & TextSources) having authority.
If you’re just looking for working chat channel support, you can find a few replacements. Namely, LegacyChat ported to TextChatService, if you want a LegacyChat (they also link a few other resources), or WinryChat.
It is disheartening that we’re having to bear the grunt of development for a Chat UI that ROBLOX should have shipped and updated incrementally in an entirely working and functional state.
I agree it is disheartening to see the lack of support and issues with the new Chat UI- and I think as-well as you said it probably shipped too soon.
My solution works for those who find this post if you still want to manage to use the CORE-UI and get its updates. But if not I also suggest using a replacement or making your own Chat UI so you have more refined control over chat in your experience.
It is good to see the community come together to attempt to solve the issues with the Chat as of recent
I can also agree. Although much may be obvious by the fact I’ve created this forum to begin with, I find it really annoying that Roblox discontinues an already existing resource for a great chat system, the LegacyChatSystem, which I initially never planned to come off; Roblox’s discontinuation of it was very unexpected and was very awkward at the time, as a lot of the features I depended on suddenly came to an abrupt halt…
Before restricting such a good resource, it would have been wise to consider all the existing factors before creating such a drastic change…
Either way, I’m going to see if I can build in the LegacyChatSystem ported over to TextChatService resource mentioned above at some point. I’ll also make sure to check out WinryChat (thanks to @extraclear for providing that to begin with)!
Hi,