The issue is burdening of the server,
I forgot to mention that once the exploiter is detected, I take away their network owner ship for around 5 seconds which means they can’t no clip, fly or speed hack, and the anti cheat won’t do further detections again if they don’t have network owner ship.
nd of the day, it’s most likely not worth preventing jumping completely server-side, but rather having a general anti-cheat system that prevents general flight and teleportation exploits etc. Preventing any jumping seems too expensive.
My anti chest protects against all common exploits, so this point is just irrelevant, please make points they you are sure are correct; as it not only saves time and prevents mid information.
I’m not wrong, and I explicitely stated that one can make effort and write a good anti-jump system .
I understand that you’re trying to contribute here, but you shouldn’t give out points which an exploiter can easily go through.
Exploiters can easily change this value any time and modifications will replicate (just like humanoid.JumpPower property), meaning they can easily bypass any further detection. They can attach a metatable, returning the same value over and over again.
This is incorrect, due to filtering enabled, exploiter modifying the value will not replicate to the server. The exploiter in no possibly way can bypass the anti cheat.
I think you can also leave out all the math flooring, since it’s not needed, and consumes resources.
Please don’t make subjective statements,
math.floor is highly needed here to get off the decimal to prevent inaccurate reading.
Second option is twice as fast in terms of performance on micro-level, but both are relatively demanding.
Both of them aren’t demanding, the first time you access
.Magnitude, it’s cached. Therefore using it again will return the cached value, it won’t have to calculate it again. To mention that taking a square root isn’t expensive at all, don’t provide such false claims.
You should also replace os.time() for time() , because os.time() only returns seconds. Any smaller jump time intervals won’t be detected.
It’s not needed at the moment, but I plan to change it to either
os.clock, as it is much better than
time, since it has high precision.
local raycastResult = workspace:Raycast(
Vector3.new(0,-ALLOWED_JUMP_HEIGHT - HRP_CENTER_HEIGHT,0)
There is also a flaw within your “high jump anti cheat code”, you aren’t accounting for the exploiters jump height / power, and I don’t recommend having constant values since they won’t get you reliable results as expected and are one of the most inefficient ways you can go about making a jump anti cheat.
You are also detecting in a single thread, which will get you quite inaccurate results, since if a exploiter suddenly exploits and goes far away from the ground for a few seconds, the code may not detect that, which is not what you want.
local floorRay = workspace:Raycast(root.Position, Vector3.new(0,-200,0))
Instead of ray casting unnecessarily, capture their last position and teleport them to that last position.
Everything else seems alright, but you can reduce number of calculation. For example:
That is just a micro optimization, no need for that. Optimization isn’t needed and only should be used if your code is performing heavy tasks frequently.
You also shouldn’t kick players unless cheating is obvious. Non-cheaters may get “flung” because of terrain bug, or have very weak internet connection, all of which may potentially kick them and eventually discourage them from playing your game.
You can just increase the threshold and use the delta time to account for lag, if a exploiter is flinged, then you can account for it by disabling collisions.