Can I have a function for getting a team by it’s teamcolor? These kind of functions appear to be common in things like the Player instance, but why does Teams not have one? It would keep me from having to write a loop every time I want to get the player’s team, which currently the cumbersome method of getting a player’s team is this:
local Team = nil
local Teams = game.Teams:GetChildren()
for i=1,#Teams do
if Teams[i].TeamColor == Player.TeamColor then
Team = Teams[i]
break
end
endI feel like it would be better if it returned only one team. I don’t think it is meant for multiple teams to use the same BrickColor.
Title typo, I actually changed it a second before you made this message xD
[quote] Can I have a function for getting a team by it’s teamcolor? These kind of functions appear to be common in things like the Player instance, but why does Teams not have one? It would keep me from having to write a loop every time I want to get the player’s team, which currently the cumbersome method of getting a player’s team is this:
local Team = nil
local Teams = game.Teams:GetChildren()
for i=1,#Teams do
if Teams[i].TeamColor == Player.TeamColor then
Team = Teams[i]
break
end
end
[/quote]
Thing is, this function is so easy to self-implement, it probably won’t happen. I’m not saying it shouldn’t happen, just not going to be an priority anytime soon. That’s my guess 
[quote] Can I have a function for getting a team by it’s teamcolor? These kind of functions appear to be common in things like the Player instance, but why does Teams not have one? It would keep me from having to write a loop every time I want to get the player’s team, which currently the cumbersome method of getting a player’s team is this:
local Team = nil
local Teams = game.Teams:GetChildren()
for i=1,#Teams do
if Teams[i].TeamColor == Player.TeamColor then
Team = Teams[i]
break
end
end
[/quote]
Thing is, this function is so easy to self-implement, it probably won’t happen. I’m not saying it shouldn’t happen, just not going to be an priority anytime soon. That’s my guess :/[/quote]
Yet this was implemented.
http://wiki.roblox.com/index.php?title=API:Class/Player/DistanceFromCharacter
Yet you could find the distance with Head.Position - Vec3 then just use the magnitude property or calculate the formula yourself.
I’m not sure this is really necessary. You can create a value indicating the team the player belongs to easily enough if you don’t want the loop every time.
Better question, why not have Player.Team and deprecate Player.TeamColor? Why was TeamColor made the depending factor in the first place?
Better question, why not have Player.Team and deprecate Player.TeamColor? Why was TeamColor made the depending factor in the first place?[/quote]
I think that would be a much better solution overall to me.
I don’t know why TeamColor was the depending factor but it seems like Teams were originally created for a very specific gameplay use case very early in ROBLOXs history. That is why things like Team.Score and Team.AutoColorCharacters were created I believe.
Even though it’s possible to get a player’s team with a loop, I still find it disappointing that we have to resort to that. I’m all for a team property. With a team color we can get a player’s team with player.Team and their teamcolor with player.Team.TeamColor, but with TeamColor it’s not the same – you can’t do player.TeamColor.Team. Player.Team would be much appreciated.
Why do you ever need the actual team object though? You already have the brickcolor, so the only thing you could learn is the team’s name. I don’t think that’s got enough use cases, especially with teams becoming less and less relevant as games become less and less dependent on roblox providing them with prefabs like this.
My RTS has units store table entries based on team, and also every unit has a .Team property, it’s often a case that I need to get the team of a player to send information to them on what a Unit just did, or from a player to locate the units that that player is allowed to effect, so unlike most games I actually depend on teams as one of the core roblox instances in my game, it’s not the Team name I want, it’s the Team’s pointer reference I use.
Teams aren’t becoming less relevant. They’re a tool that anyone can use. Even if you’re not a capable programmer (most people on ROBLOX), you’re still able to use teams to create a game. You can create all sorts of games with teams. Every ROBLOX obby uses teams, the ROBLOX competitive templates (capture point for instance) use teams, war clans use teams at their forts/training courses, Pizza Place (the top earning and the most popular ROBLOX game over time) uses teams, Prison Life (also a front page game) uses teams, Phantom Forces, developed by programmers easily capable of making custom teams, uses the default teams (If you open up one of the exploited copies you can see that they use actual teams), Miner’s Haven (another front page game) uses teams, etc. Teams are still relevant and they won’t die out any time soon if at all.
As for reasons why it should be player.Team instead of player.TeamColor, player.Team provides more information. It provides direct access to the player’s team name, team color, and anything parented to the team object (I’ve seen people frequently parent a backpack to team objects and clone in the contents as if the backpack was the team’s starterpack). That alone is enough reason to use player.Team instead of player.TeamColor which only provides the team’s color and not its name / children. In addition to that, if you’re reading through script sources, a team’s name is much more concise than its teamcolor. I would much rather read (and be able to understand) (if player.Team.Name == “Defenders” then) over (if player.TeamColor == BrickColor.new(“Bright blue”) then) – using team name makes scripts much more readable.
It also makes elsewhere more readable. In one of my games I use a custom spawn system – the game hierarchy is set up so that spawn parts (not actual spawnlocations) are parented to a model called “SpawnsTeamname”. It’s much easier to tell which spawns belong to who when I see “SpawnsAttackers”, “SpawnsDefenders”, “SpawnsSpectators” over “SpawnsReally red”, “SpawnsBright blue”, and “SpawnsInstitutional white”. Currently I just fetch the team object based on the player’s teamcolor and find the spawns that way because there’s no way I’m naming my spawns “SpawnsInstitutional white” or the like, and it’d be much better if I could replace that loop with player.Team.
I would much rather have a Player.Team property and then a method Team:GetPlayers(). That covers all the use cases I can think of.
Going to bump this as it would be very useful and easier for programmers who use teams as a main priority with their game.
At the moment, I do think having Teams:GetTeamFromColor("Really red") would become extremely HELPFUL so it can detect if any of the teams inside the game are the same BrickColor as what is being called into a script and even much easier to remove/move players to one team to another with BrickColor.
Anyway, having Teams:GetTeamFromColor("Bright green") or any replacement like Player.Team and Teams:GetPlayers() / Teams:GetBrickColor would somewhat work for teams. Personally speaking, I would like to see this feature come into the Engine one day and even using it.
local Teams = game.Teams:GetTeams()
--or:
local Teams = game:GetService("Teams")
^ Still handy and works fine, but having it detect a certain team color would probably be more helpful.
If something like this were ever to get added, I guess it would be very beneficial and most likely use it for many of the reasons above me. 