i just said that.
Its also called exploiting not “hacking”
wdym the client cant delete serverscripts
I changed the anti exploit to a server script.
good :D, how long did it take, that was fast!
Make sure you fix the code so that it dosen’t use LocalPlayer, you’ll have to use Player.CharacterAdded/PlayerAdded(blablabla, etc).
1 Like
All I had to do was add two server scripts for the anti exploit and copy and paste them into starter character scripts.
Ok, so there’s some set backs to changing it to a server script. The main thing being, it sees only things change on the server. The client using their exploit, whatever it may be, will always only change things client side, unless they fire an event. By checking if something is removed from the character it will always fail, as it will only be removed on the client. They will be able to exploit freely, despite what the server script may say, because it only has insight into the server.
2 Likes
But local scripts can be completely removed, I don’t really see why switching back to local script would be a good idea at all either way.
Plus, with some trickery, you can detect the average speed of the player and see if they’re going over the limit 
Same goes with velocity, parts, etc.
1 Like
unfortunately, some exploits have a method/function called getconnections(), it returns the functions connected to event you passed with it as an argument as a table, so with that function you could easily get the events connected to the script, and disable them, and voila, they’ve bypassed your anti exploit.
What I’m saying is, and he is detecting for things removed from the player in the script that he posted, they will remain there for the server, unless directly removed by the server.
Just to better visualize it, lets say the player runs their exploit, and just does player.Character.Humanoid:Destroy(). Since this is run in a client sided application, the server has absolutely zero clue to if the humanoid is still in there. And since it can’t see client sided changes, it is led to believe it is, which in turn results in no action being taken against the player.
Now I hear what you are saying about the local script just being able to be disabled. Yes, it can very easily be. But the protection the server script gives, versus the protection a local script would, is much higher in the given situation.
I bet there is better ways to detect it and not have your script get disabled, and maybe have two local scripts that both check each other for their existence(never tried it, just a thought so it could fail.) The exploiters have so much power, and you can play cat and dog with them all day, but they will most likely come out on top. It’s all about damage resistance, and keeping your game playable even if an exploiter happens to pop in.
1 Like
Btw @DarkDanny04 Deleting objects that aren't BaseParts from your Character on the client replicates to the server - #26 by SaltyPotter
If I’m not wrong, players can actually alter/change things in the character so that might not be a good place to put it. (Only some parts though, you can test it in studio if you’d like.)
@TheDemoDeveloper Just put it in ServerScriptService, safest spot, and if you need to get the character:
local Players = game:GetService("Players")
Players.PlayerAdded:Connect(function(Player)
Player.CharacterAdded:Connect(function(Character)
-- "Character" is the actual character.
end)
end)
Also:
One last thing I’d like to point out, there is a pretty cool test of an anti-cheat that you can try and check out yourself. It gives you a console to “cheat” with so you can test it.
Demo Video:
https://twitter.com/LM_loleris/status/1268591090036285446
4 Likes
Ohh, I had no clue about the server replication thing with characters. Thank you for educating me on the topic!
4 Likes