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
Players.PlayerAdded:Connect(function(Player)
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
print(i)
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
else
Plr.Team = Blue
end
end
end
end)
Players.PlayerRemoving:Connect(function(Player)
PlayerCount -= 1 -- Removes 1 for every Player that leaves the game.
end)
6 Likes
Just a correction, here:
You are rechecking, that’s not needed, just do:
else
Plr.Team = Blue
2 Likes
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.
3 Likes
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.
2 Likes
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)
tab1()
return if rawget(tab1, 1) % 2 == 0 then true else false
end,
__call = function(tab)
local initialValue = rawget(tab, 1)
if not initialValue then
initialValue = 0
tab[1] = 0
end
rawset(tab, 1, initialValue + 1)
end,
__newindex = function(tab, index, value)
rawset(tab, index, value)
end,
})
local first = a == a
local second = a ~= a
if first ~= second then
print("Every element is considered in the universal set")
else
print("Impossible without metatables!")
end
Prints Impossible without metatables!
Correct me where I’m wrong, please!
4 Likes
So, does this mean that the script I wrote would work anyways?
I don’t understand very good 
1 Like
Yep, you are fine with the else block as long as you dont have your tables with metatables attached.
2 Likes
Thanks for your feedback, It has been fixed!