yes, but why don’t you just check how far away they are from their old position on the server?
That’s what I said, magnitude can do that
This seems like an issue on your side. It still runs smoothly on my side. Try debugging it yourself like checking is there a remote in the Player instance like this
or some prints to see what works and what doesn’t. I just edit in 3 prints into the original script, it should output this.
From your video, it seems like the initial location wasn’t taken. Maybe Player.Character wasn’t accessible on the server (some games have this) or the script was disabled and didn’t run at all.
Make sure the scripts are in the right locations (ServerScriptService/Workspace for the server script and StarterPlayerScripts for the client script), as their own instance. Don’t paste it into an existing script. Make a new script instance then paste it in, to avoid some overlapping. Also, make sure _G.Locations is used correctly. It only takes Vector3 values.
You can. It is just likely to have false positives if you have an unstable ping when checking entirely on the server. Additionally, the magnitude check will have to be a very high number meaning the client can increase their speed from 16 to 20 or higher with no problem but with this, if you change your speed from 16 to 17 you will be teleported back.
Friendly reminder that this anti walkspeed doesn’t take account in physics.
Since the exploiter can edit the arguments it is also bypassable by replacing the position with a NaN Vector like so:
local Player = game:GetService("Players").LocalPlayer
local updatecharacter = Player:WaitForChild("RemoteEvent")
repeat wait() until Player.Character and Player.Character.PrimaryPart
local deltatime = os.clock()
while task.wait(0.1) do
if Player.Character then
local a = os.clock()
updatecharacter:FireServer(a - deltatime, Vector3.new("NaN","NaN","NaN"))
deltatime = a
else
local a = os.clock()
updatecharacter:FireServer(a - deltatime)
deltatime = a
end
end
Oh, I forgot a Vector can have NaN values aswell. Thanks for reminding me. You can see me preventing time to be NaN with dt == dt
Though I’m unsure can you get the magnitude of that NaN Vector (and perform the subtract operations with it) but I’ll make a check.
Edit: It’s possible to do math operations with it though it doesn’t change the NaN value at all.
The script has been edited to prevent an axis in the Vector3 sent to the NaN.
You could easily spoof player position in the firing on the remote. As long as it doesn’t deviate by ~20 studs, the exploiter is safe.
I feel like this is made with a lack of understanding of the potential of inaccuracies and false positives that occur in a real-world environment. I recommend a rubberband approach when it comes to characters exhibiting unnatural movement, as it’s more likely to be related to a poor connection than exploiting. Anyone wishing to implement this should rewrite this entirely to fit with the environment of their game.
Additionally, relying on the client for position information means this is fundamentally bypassable.
easy way to bypass this
localscript.Disabled = false
while task.wait(5) do
thefrigginremoteevent:FireServer(deltatime,Vector3.new(0,0,0))
end
and yes, it does work
I disagree with you once and had to come over here, make a post that is just… unprofessional.
Anyhow, that does not work. As I do have a magnitude check at the end of the server script. Additionally, I asked everyone who uses this to use _G.Locations to get the player location. If they do that, whatever you do with the position, won’t work.
Do you think there would be any way to teleport the player without triggering the anticheat?
like a boolvalue or something?