How Efficient Would This Anti Exploit System Be?

Making an AntiExploit System. Thoughts on Efficiency - Help and Feedback / Code Review - DevForum | Roblox

Hi there, you may have heard about the exploit that can frame you if you have your game still public. I understand that it might be fixed soon, but in the meantime, I wanted to make this system to ensure that the game can defend well against this exploit.

I just want to know if this would work against the current exploit and if there are other things I should improve on to strengthen this system.

local function removeanims()
	for i, item in pairs(game:GetDescendants()) do
		if item:IsA("Animation") or item:IsA("Animator") or item:IsA("AnimationTrack") then


		p:Kick("Locking Server For AntiCheat Protocol")
		for i, player in pairs(game.Players:GetChildren()) do
			player:Kick("Locking Server For AntiCheat Protocol")
	for i, player in pairs(game.Players:GetChildren()) do
		player:Kick("Locking Server For AntiCheat Protocol")

repeat wait(5) until #game.Players:GetChildren() > 0


Before responding, you should know something about the format I am going for.

The game is pretty much more of a 2d game with Guis covering the entire screen and does not involve the actual 3d part of the game. This means avatar animations will not be important to me as of now.


As that’s Client sided (or at least it seems) that’s easily exploitable

This script is in server script service.

Oh okay it just seemed Client sided to me, well, that should work, only thing is that a very advanced Exploiter could put an animation that isn’t an animation but uses CFrames and that kind of things, in that case this is useless


Ok, thank you for letting me know. I might make another post like this when I make an updated version of this Anti cheat system.

One question. Can that exploiter manipulate anchored parts?

Obviously, they can manipulate everything on their Client

1 Like

ok, thanks for letting me know.

Quick explanation:
Think of it this way:
Everything the Client sees is Exploitable, every Local Script is exploitable, very RemoteEvent that talks with the Client is exploitable
Basically everything that interacts with the Client is exploitable

  1. exploiters can’t delete script’s in serverscriptservice
  2. this won’t work because all a player has to do to bypass it is reset (it possibly won’t even start up when someone’s character first loads)
  3. animations don’t have to be parented to be used and the humanoid comes with an animator
  4. you’re better of checking the animation id that is currently running on the humanoid from the server (I think it’s called :GetPlayingAnimationTracks() might be deprecated but it works)
1 Like

This really won’t do anything because exploiters can’t play animations If the game is r6 they can move them with CFrames, but you couldn’t tell by detecting an object either. Even if they did somehow insert an animation, the serverscript would have no way of knowing. (because of FE)

Fairly sure animations replicate to the server

They only would if the server created them, but in this context, there is no reason for the server to create animations other than default Roblox anims. Filtering enabled makes it so if the client creates something, the server doesn’t get affected. Exploiters couldn’t insert an animation on the server unless there was a remote event that creates the animation. Even with that, it isn’t dangerous, unless you allow the client to choose the assetId(as a parameter) as well.

I just tested it, I played an animation on the client and it still ran on the server

How did you run the animation?

By using Load animation on the humanoid

The first of these loops inside PlayerAdded is completely redundant.

for i, player in pairs(game.Players:GetChildren()) do
	player:Kick("Locking Server For AntiCheat Protocol")

To avoid duplicate code, I would do something like this instead:

local Players = game:GetService("Players")
	local function Kick(Player)
		Player:Kick("Locking Server For AntiCheat Protocol")
	for _, Player in ipairs(Players:GetChildren()) do

And since GetChildren() returns an array with numeric indices, ipairs() will be faster.

Also, repeat wait() until ... are generally bad news and could be replaced by a more efficient way. Use Players.PlayerAdded:Wait() instead.