Sorting players into 2 teams

local Players = game:GetService("Players")
local Teams = game:GetService("Teams")

local Blue = Teams:WaitForChild("Blue") -- Insert a Team into Teams and name it Blue
local Red = Teams:WaitForChild("Red") -- Insert a Team into Teams and name it Red.

local PlayerCount = 0 -- The Player Count

    PlayerCount += 1 -- Adds 1 for every Player that joins the game.
    if PlayerCount >= 2 then -- Change the 2 with the amount of players it'll take to be in the game before it distributes them all into their teams.        
        for i, Plr in Players:GetPlayers() do
            if i % 2 == 0 then --The % operator. It gives you the remainder of two numbers after division. If i / 2  does not have a remainder, then 0 is returned, therefore sorting even numbers from odds. For every 0 that is returned, the corresponding player will be sorted onto the red team.
                Plr.Team = Red
                Plr.Team = Blue

    PlayerCount -= 1 -- Removes 1 for every Player that leaves the game.

You have to give an explanation to put this in #resources:community-tutorials


Just a correction, here:

You are rechecking, that’s not needed, just do:

Plr.Team = Blue

The OP’s snippet is more accurate.

There are other potential situations where the player’s team could be incorrectly changed to blue, which is why it’s good to make the condition specific.

I was wrong. Please see @ProBaturay 's reply.


Like, he’s checking if the number isn’t equal to 0, if it isn’t then move them to the Blue team, I don’t udnretand what’s wrong with my scriot

Also when is a situation where this would be wrong?

1 Like

Okay, understood now

Also, that equation will return 0 only if the number is even, checked with the calculator

1 Like

hey there buddy thats not a tutorial its more of a resource. If you dont know tutorial is an explaination and you arent explaining anything, I dont mean it in the code. Either change the category to #resources:community-resources or just lengthen the topic a bunch.


Programmatically, this behavior is accurate, but semantically it leads to redundancy in the code.

We know the variable i will return a whole number starting from 1 every time the loop goes back to the beginning and we acknowledge the fact that the divisor is bigger always than the remainder in a division operation. The modulo operator performs the operation with 2, which means the remainder will evaluate to either 0 or 1 because i is a whole number.

This is not necessary as the second condition will evaluate to 1, regardless of the “not equal to” operator.

One of the conditions will always give the intended result because both “equal to” and “not equal to” operators were used in the same value comparison. To expand the topic, the elements that are checked in the first and the second condition constitute a universal set.

If we involve metatables, the following diagram shows up.

Green areas show conditions that evaluate to each other at the same time, which could only be done using metamethods.

An example that demonstrates how == and ~= evaluate to false or true at the same time.

local a = setmetatable({}, {
	__eq = function(tab1, tab2)
		return if rawget(tab1, 1) % 2 == 0 then true else false
	__call = function(tab)
		local initialValue = rawget(tab, 1)
		if not initialValue then
			initialValue = 0
			tab[1] = 0
		rawset(tab, 1, initialValue + 1)
	__newindex = function(tab, index, value)
		rawset(tab, index, value)

local first = a == a
local second = a ~= a 

if first ~= second then
	print("Every element is considered in the universal set")
	print("Impossible without metatables!")

Prints Impossible without metatables!

Correct me where I’m wrong, please!


So, does this mean that the script I wrote would work anyways?
I don’t understand very good :sweat_smile:

1 Like

Yep, you are fine with the else block as long as you dont have your tables with metatables attached.


Thanks for your feedback, It has been fixed!