This is what I currently have in my anti-cheat script.
game.Players.PlayerAdded:Connect(function(player)
coroutine.wrap(function()
while fastWait(1) do
if player==nil then break end
I have a coroutine because I also running another loop at the same time:
while fastWait() do
if player==nil then break end
Is breaking the loop if the player is nil good practice? Will this lead to using less resources on the server? Is there a better way to do anything in this script?
Uh, it’s quite udmb what you doing.
I don’t understand why you even do this.
Just connect when player leaves in the PlayerAdded event and any event you need there.
local e = {}
game.Players.PlayerAdded:Connect(function(p)
local changedevent
changedevent = value.Changed:Connect(function()
end)
e[p] = game.Players.PlayerRemoving:Connect(function(pl)
if (pl ~= p) then
return
end
--do whatever u want
if (changedevent) then
changedevent:Disconnect()
end
e[p]:Disconnect()
end)
end)
I’ve personally never had an issue with it. It catches most of any event fails. If there is another reason as to why playerremoving doesn’t fire I wouldn’t be sure of. most loses are causes because of the game closing.
I’ve tested this multiple times in studio, game:bindtoclose always seems to catch it. without it, it would rarely save at all.
But if both of my loops are broken when the player leaves (player==nil), there would be no more code in the function running. Wouldn’t that be the same as just disconnecting the function?
Have you had any problems prior with PlayerRemoving? If so have you actually tried BindToClose? What are the results?
Lets say you have a loop constantly looping through a table and checking values in it, the more it loads the more it has to do.
I personally like to keep the same category of loop in 1 single loop, and creating a new loop for every player to check if it exists just seems far more inefficient and stressing.
Depends there might be an inbuilt event for what your doing, what value are you constantly checking? (Events would be performant since the run the functions connected to it ONLY when the thing happens internally.
Actually there’s no event for walking, so for constantly checking you can do one optimization don’t run the checking code if the previous velocity is the same as the velocity now, for the velocity checks.
It only doesn’t fire if the server is shutting down, and it’s rare to see it not fire even if the server is not shutting down therefore it’s reliable.