Basically for anti-noclip and anti-tp I want to have a while wait(.5) do loop that checks the magnitude of the location the player was in .5 seconds ago and if its greater than a certain range it will kick them for TPing. I also want to raycast between the two points to detect noclip.
Would this hurt performance by doing a loop every .5 seconds for every player? (My games max players will be anywhere from 30 - 40. I haven’t fully decided yet)
I also ran a test with only 2 players but instead of looping every .5 seconds I did it every runservice.heartbeat and it crashed the server with only 2 players. So I wonder if the increase to .5 can prevent lag / crashing.
My raycast function is a bit different. Would this effect anything?
this is my raycast function which can filter out parts and add them to a global blacklist.
local function raycast(char,origin,direction,blacklisttable)
table.insert(blacklisttable,1,char)
local raycastParams = RaycastParams.new()
raycastParams.FilterDescendantsInstances = blacklisttable
raycastParams.FilterType = Enum.RaycastFilterType.Blacklist
local raycastResult = workspace:Raycast(origin,direction,raycastParams)
if raycastResult then
local hit = raycastResult.Instance
if hit.CanCollide == false or hit.CollisionGroupId ~= 0 then
return raycast(hit,origin,direction,blacklisttable)
else
blacklisttable = {}
return raycastResult.Position
end
else
blacklisttable = {}
return nil
end
end
Also, my game is PC only so I don’t have to worry about mobile users lagging.
Also assuming you already know this but just incase. My code runs on the server and not the client.
Instead of creating a new raycastParams each time perhaps you can try caching the raycastParams for each player the first time you create and then later just update its FilterDescendantsInstances which could be better I assume.
60 to 80 magnitude calculations a second is nowhere near what you need to lag the server. Raycasts are also unlikely to be laggy. The best way to find out what lags the server is to test it for yourself.
Before I ran a test with runservice heartbeat and the server was incredibly laggy and eventually crashed with 2 players.
Running this code into command bar:
local te local rs = game:GetService("RunService") te = rs.Heartbeat:Connect(function() print("h") end) wait(1) te:Disconnect()
it prints around 50 - 60 times. So while we were in-game it was running the code 100 - 120 times a second. The server was incredibly laggy and choppy and I left my friend alone. The server crashed like 20 seconds later while he was alone so my loop had stopped so at this point it was only running at 50 - 60 times a second. So idk.
Most modern processors are like ultra optimized for raycasting and can do it like a breeze, print statements are definitely a lot more lag inducing than most people think too
Damn thats crazy. I didn’t know that.
Do you think it’d be fine to run a while wait(.5) do loop that raycasts and checks magnitude?
Just collecting opinions from everyone atm.
Tested on mobile and as you can see its faster on mobile, however it shouldn’t matter in his situation since its in server but squared magnitude is still faster in mobile
Also my code has to do a magnitude check twice. Would it still be safe to run?
This is the actual code.
while wait(.5) do
if not plr:FindFirstChild("tpsafe") then
if (char.HumanoidRootPart.Position-Vector3.new(lastloc2.Position.X,char.HumanoidRootPart.Position.Y,lastloc2.Position.Z)).Magnitude >= tplimit then
punish(plr)
break
elseif (brick.Position-lastloc.Position).Magnitude >= distlimit then
local rc = raycast(char,brick.Position,brick.Position - lastloc.Position,blacklist)
if rc ~= nil then
tpfunction(char)
if lastlocdb == true then
lastloctimer = 5
else
lastlocdbfunction()
end
end
elseif lastlocdb == false then
lastloc = char.HumanoidRootPart.CFrame
end
end
lastloc2 = char.HumanoidRootPart.CFrame
end
oh absolutely, i was once so confused as to why my code was laggy but it was because while working on it i put in a lot of print statements and they were causing the issue xD, took me an afternoon and a headache to figure that one out
