So for the most part I’ve done smaller scripting jobs for low traffic areas. Although, soon some of my scripts will have very HIGH traffic from a employer. For the most part I have been able to do basic events inside events. For example.
game.Players.PlayerAdded:Connect(function(plr)
plr.CharacterAdded:Connect(function(chr)
chr.RightArm.Touched:Connect(function(hit)
-- Obviously this is a very poor example of this, but you get the point...
end
end)
end)
I aint no genius, but it seems to me that this will cause problems in the future where there will be 10’s of thousands of players on at once since the script is having to stay in one spot to constantly check this… Just checking to see if I am just paranoid or if this is a real problem. Any feedback is appreciated!
To add on to this, even if you could have thousands of players in one server, the script in the post would still work as the Players.PlayerAdded event always fires for each player joined. Hence the chr.RightArm.Touched:Connect(function(hit) will always be run for each player.
I’m guessing what you’re worried about, is that after the server has been running for say, 10 hours, thousands of players could have potentially joined and left within that time, creating loads of events. If so, you don’t need to worry about that. When an object is destroyed, like the players character, or the player object itself, all connections to that object are recursively disconnected. This means you will only ever have as many CharacterAdded and RightArm.Touched connections in your server at one time as there are players in the server.
Alright, the example that I had here was very poor, let me give another…
In this one I am running a for loop with making all of these parts and sending them to random locations. If one gets touched, it will then damage the player…
for i=1, NumberOfParts do
local part = Instance.new("Part", workspace)
game:GetService("Debris"):AddItem(part, 2)
part.Name = "LeafEffect"
part.BrickColor = BrickColor.new("Grime")
part.CanCollide = false
part.Anchored = true
part.Size = Vector3.new(1,.2,1)
part.TopSurface = Enum.SurfaceType.Smooth
part.BottomSurface = Enum.SurfaceType.Smooth
part.Transparency = 1
part.Position = position
part.CFrame = CFrame.new(position, part.Position + Vector3.new(math.random(-10,10),3, math.random(-10,10)))
table.insert(AllParts, part)
local LeafImage = script.Parent.Leaf:Clone()
LeafImage.Parent = part
LeafImage.Enabled = true
part.Touched:Connect(function(hit)
if hit.Parent:FindFirstChild("Humanoid") then
if not hit:IsDescendantOf(script.Parent.Parent) then
hit.Parent.Humanoid:TakeDamage(DAMAGE)
local gui = Instance.new("BillboardGui", hit.Parent.Head)
gui.Size = UDim2.new(10,0,2,0)
gui.StudsOffset = Vector3.new(0,3,0)
local Label = Instance.new("TextLabel", gui)
Label.Size = UDim2.new(1,0,1,0)
Label.BackgroundTransparency = 1
Label.TextColor3 = Color3.new(255,0,0)
Label.TextStrokeTransparency = 0
Label.Text = DAMAGE
Label.TextScaled = true
game:GetService("Debris"):AddItem(gui, .5)
plr.XP.Value = plr.XP.Value + XPPerKill
part:Destroy()
end
end
end)
end
So right now I have the number of parts shooting out at 50. Meaning if there is a 25 player server and everyone is spamming this tool, it would be looking at that loop 1250 times in a matter of seconds…
So what most of you said about the PlayerAdded event was very true, it is not anything to worry about. It was solely for a example of what I am talking about.
This is perfectly fine. Though, a better solution might be range checking to see if the user is close enough to a part (and low enough maybe?) to be reasonably hit? That’s only if you’re really worried about efficiency though.
It’s a balance between functionality and efficiency, as always.