Then that’s your opinion, if you actually knew how exploits work and how the client has access to everything on their machine, you’d say otherwise.
I do understand how exploits work, but I’ll still stick with my opinion 
@Syclya the fact is that client can access almost anything on their machine. Like said before, exploiters can modify any code, run any code on their end, or stop any active processes. No way to counter that. However, @EmeraldLimes has a point. Client sided checks aren’t impossible, but they are avoidable by the exploiter. Both of you are right, as even though clients can disable hidden local anti-cheats, those can and really do work as a - at least temporary - side kick to server anti-cheat system.
Many cheaters are inexperienced Roblox players that often don’t know anything about programming, leave aside game architecture. They learn how to download and install script executors by watching YouTube “tutorials”, and/or repeat steps described on forums that border to grey area.
Clients sided anti-exploits can be easily bypassed, but that doesn’t mean everyone will know how to bypass them, albeit the ones who do know the ways will eventually release them publicly.
Long story short, a glass fence may not be able to stop a bear, but that doesn’t mean smaller animals can break it (until they perhaps find the right tool).
Nothing is wrong with adding some small anti-cheats and honeypots on client. But more importantly, a solid general server anti-cheat and good game architecture are a must.
EDIT @Syclya @EmeraldLimes
That’s the key sentence. The more popular a game is, the faster will exploiters find local security checks and disable them. Once they find the scripts, it’s as easy as disabling them. The only thing one can do to counter that is update the game and change the local anti-cheat, or hide it elsewhere etc. Perhaps hide it in other scripts. It’s often considered ineffective, because regular updating is demanded. A step forward would be implementing polymorphism and self-relocating, but that requires a lot of work and is most likely not worth it nor, again, as effective.
For the reason explained above, there are also no effective “injection detectors”. Besides, exploiters don’t even have to inject scripts, but rather run executors, which run in memory without attaching any objects into the game environment.
1 Like
I agree. To add onto why I think client side checks are worth a try, if you make it strong enough, than (hopefully) only experienced hackers can crack them. Chances are, they’ll offer it for a price, which (I think) will reduce the number of exploiters that can get past it significantly.
You can keep improving your system until the only scripts that can get past it are offered at high prices, or, maybe no one can get past it. Who knows? 
Just a theory, of course. I’ve heard of a game that was able to detect an “injector” when it was “attached” to the game, and was able to kick the exploiter
I have also heard about a game that can detect injections, however that is most likely from a CoreScript used by the admins, a CoreScript has the highest (don’t see why not) permission level, they can even change your in-game volume if they want to:
I wouldn’t waste my time implementing something that can be removed within a few seconds, I don’t see myself doing so much work when it’s easily bypassable by the client.
You will however get rid of a lot of exploiters as most are inexperienced, but you will never keep out the ones that knows what they’re doing, that’s why I don’t want to implement client checks in the first place.
Literally anyone can bypass it if they want to, so in the end it doesn’t matter how skilled they are because most exploits has a lot of built-in functions that can help the user bypass whatever they want.
Never trust the client.
Once they find the scripts, it’s as easy as disabling them. The only thing one can do to counter that is update the game and change the local anti-cheat, or hide it elsewhere etc. Perhaps hide it in other scripts. It’s often considered ineffective, because regular updating is demanded. A step forward would be implementing polymorphism and self-relocating, but that requires a lot of work and is most likely not worth it nor, again, as effective.
They don’t even need to find them in order to completely remove them.
They can access nil and every localscript in the game:
pcall(function()
local GetDescendants = game:GetDescendants()
for i = 1, #GetDescendants do
if GetDescendants[i]:IsA('LocalScript') then
--
end
end
end)
-- Synapse X (and very likely other exploits that looks similar when accessing nil)
local GetNilInstances = getnilinstances()
for i = 1, #GetNilInstances do
if GetNilInstances[i]:IsA('LocalScript') then
--
end
end
As long as the localscript exists in the client’s memory, they will be able to find it, regardless.
This is pretty hard to implement, as latency can cause a lot of false positives. In fact, it was easier for me to create an autoclick detector than it is to create a working version of this. I’m not sure if Roblox needs improve the reliability of HumanoidState’s or if this will always be like this.
Hi! Yes, I understand that, thank you. I think I mentioned everything when I said that client-sided anti-cheats may often be ineffective, but may still sometimes serve as side kicks for good general anti-cheat system along with good game architecture.
What you said is true, but again, not everyone knows programming and not everyone will know how to remove/disable for instance an unnamed local script that has a hidden anti-cheat inside lets say character controller. An inexperienced player won’t know how to remove the anti-exploit without fataly spoiling their game experience. Not effective, not completely ineffective.
@BuilderBob25620 those auto-click detectors work, but can be easily bypassed by using the methods already mentioned in this topic. However, it’s important to do server checks if server actually has to process those clicks.
I don’t know why HumanoidStateType is still in question. It’s a good idea, but runs client-side. I’ve assambled some basic raycasting code right at the top of this topic:
About false positive results:
@Syclya and @BuilderBob25620 the negative effect of potential false-positives is almost negligible with this server-sided anti-high jump, because it depends on set jump limit. If players can jump 7.2 studs high, we can set the limit to 30 studs. Besides, we can store attempts. Each time player passes the limit, teleport them to the ground, but keep score on how many times it happened and so on.
The odds of players jumping 40 studs high multiple times (not falling) while being limited to 7.2 are very low.
You’ve both made some fair points.
Not really. I built a system where any click you did HAD to be processed by the server for any clicks to work. Otherwise if you were trying to press a button or something and it wasn’t being sent through the server then it wouldn’t work. And it only sent the bare-miniumum of information, meaning it just fired whenever the mouse was clicked and provided the player who fired the remote event on the server-side by default. Everything else like timing and interval detection was handled on the server. I also made it gave a minimum amount of time you were allowed to click fast enough to be within the interval, because in real life a human clicking very fast will wear down with time but a computer can keep on going. I believe I set the allowed time around 10-15 seconds.
Despite this, I realize my autoclick detector could still be bypassed if the clicks were setup to be random and varied. Still, in those cases it wouldn’t matter because the main reason I created it was to prevent inhuman clicking, not people staying on the server too long.
1 Like
Not sure what you mean here, game devs cannot access core scripts, no?
I know, it was meant to be an example of what was (maybe) thought impossible, was made possible
I guess what my point is, it doesn’t hurt to try. Maybe there are methods not explored, or weaknesses overlooked.
I suppose I just don’t think it’s impossible, rather we haven’t found a solution yet. I would still go with server sided checks rather than client checks though.
@Syclya and @EssenceExplorer both made some very valid points, I’d like to apologise if I sounded snobbish, annoying, and maybe naive in any way.
I probably don’t have as much experience in this field as you guys do.
Have a nice day! 
i haven’t made one myself but AFAIK you make a script that kicks the player if they sit. this might not work though, i dont know if scripts still use the jump → sit → jump scripts
I said they can only be used by admins, not regular game devs.
Gotcha. Sorry for the confusion.
1 Like
There are certain points I would like to mention about your code. First, the ray casting is flawed. It’s very possible that the ray might hit the player it self, in which you need to set up ray cast params for that.
Second, you should determine their position on ground by ray casting instead of checking if their current position’s Y is greater than the previous, that would get you more accurate results:
while (true) do
for userId, root in pairs(rootParts) do
_humanoid = root.Parent.Humanoid
-- Cast a ray with allowed magnitude downwards.
local raycastResult = workspace:Raycast(
root.Position,
Vector3.new(0,-(_humanoid.JumpHeight + _humanoid.HipHeight + ALLOWED_ADDED_JUMP_HEIGHT),0)
)
-- make sure to handle ray cast params ^, also handle network ownership
-- Make sure the ray hits on a can collide object
if (raycastResult and raycastResult.Instance.CanCollide) then
lastPosition[userId] = root.CFrame
else
if raycastResult then
root:SetNetworkOwner() -- take away their network owner so they fall down
elseif root.Position.Y > lastPosition[userId].Y then -- make sure player isn't falling
root.CFrame = lastPosition[userId]
end
end
end
-- raycasting every .2 seconds is ok
wait(.2)
end
Third, you should set their CFrame back to their previous instead of destroying their head. You also don’t account for players standing on a can collide false object.
Floor material can easily be exploited, since the player has network ownership, physics properties are calculated from the client. An exploiter can simply put an part relative to them on the client and probably weld or set it’s CFrame constantly, and the server will think they are on the ground.
ty i was searching for it for a long time bc my script failed multiple times
It is not the exact solution though, it may cause some errors due to delay and get deleted by cheaters. You’re welcome anyway.
nah i have made a script that if any anti cheat script get deleted it will kick them ty btw
That is nearly impossible, I guess. The cheater can suddenly delete the anti-cheat script, including that script, and use exploits as long as the script doesn’t exist. Well, maybe you could use a while loop in a server script that clones a script from where that client couldn’t reach. But it can also get deleted as soon as it’s cloned into the player. These are just a piece of advice to be protected from the exploits in better ways.
If this had been possible, Roblox would have already solved the problem. As I mentioned above, this is nearly impossible to detect whether they are using exploits.
ty for the idea i will use it but i think it will cause lagging if i made a loop bc how many scripts are there