Expected behavior
The Creator Hub’s TextChatService page describes a behavior in which TextChannel
instances are added or removed to match when Team
instances are added or removed:
Presumably, this setup is designed in a way to ensure nonexistent Team
s are not polluting the TextChatService.TextChannels
folder with unused TextChannel
s.
The issue
The intended behavior is to automatically remove team-based TextChannel
s whose matching TeamColor
is no longer held by an active Team
.
While this works when creating and destroying Team
instances, it falls apart when the developer changes an existing Team
’s TeamColor
property.
In this example, I am running a Play session in Server mode. Notice how by changing the TeamColor
, it creates a new TextChannel
, but does not delete the TextChannel
associated with the prior TeamColor
:
-
At 0:04, I insert the first
Team
, which has aWhite
TeamColor
by default. ATextChannel
namedRBXTeamWhite
is immediately created to accomodate the newTeam
. -
At 0:12, I change my
Player.TeamColor
property fromBlack
, which had no associatedTeam
instance, toWhite
, the sameTeamColor
as the newTeam
. A newTextSource
is automatically created underneath the existingRBXTeamWhite
TextChannel
, allowing my client to callRBXTeamWhite::SendAsync
. -
At 0:21, dozens of new
TextChannel
instances are created as I move my cursor across theTeamColor
selection wheel. Even though only oneTeam
exists, and therefore only one validTeamColor
, all the now-unusedTeamColor
s continue to have associatedTextChannel
instances. -
At 0:31, you can see that my
Player
’sTextSource
remains under theRBXTeamWhite
channel, despite there no longer being aWhite
Team
.
If a Team.TeamColor
property is changed, and the old TeamColor
property value does not match that of any remaining Team
s, the associated RBXTeam TextChannel
should be destroyed.