Complete guide of how to make an anti exploit!

Resources Community Tutorials
, ,
#14

It does not show how to stop players from abusing remotes.

Most exploiters are not that dumb. You shouldn’t make up fairytale examples because they do not reflect reality. An actual exploiter will figure out the upper limit for what they can request and just sit there firing the remote repetitively for 20 minutes.

This works as a honeypot sure, but accounts are expendable, and they’ll figure it out eventually. You’re better off not doing this at all.

8 Likes
#15

What about the time limit? they can not spam it if the cooldown is forsay 300 seconds (5 minutes) - Also the post was rushed and I said i will continue updating it

2 Likes
#16

If the time limit is 5 minutes then the reward loop of your game doesn’t work for 5 minutes.

Don’t rush tutorials and resources. These are meant to help people, not to get cheap attention. You do more harm than help this way.

8 Likes
#17

Instead of limiting the money or do some cooldown on the remote , just do it in the server. There’s no reason to handle money giving on the client

2 Likes
#18

To add, the server should be completely orchestrating the gameloop. It should be deciding when to award money, you should never need a remote for this.

5 Likes
#20

I had rushed It since I wanted to help people make “anti-exploit” and was In a hurry of alot of stuff to do - as I said I will be updating It constantly, editing…

2 Likes
#21

I agree with this 100%, but some people still use money remotes for literally no reason

3 Likes
#22

So just tell them to not, maybe try showing them sanity checks with a shop gui

2 Likes
#23

I will thanks for the suggestion, I’ll probably edit it tomorrow its like 6 PM for me, and i have some stuff to do

2 Likes
#28

The guide has been updated for better remote security! adding more for example magnitude checks soon… (how to do magnitude checks)

1 Like
#29

Added magnitude check! :wink: Give me more ideas of what to add :smiley:

#30

ok, just a small question but where would you recommend putting the anti-cheat?

#31

ServerScriptService, as an normal script.

#32

Added Reach Detection! (I forgot to post this when i added it lol, it was added a week ago) → Give me more suggestions of what to add.

#33

This reach detection is not reliable - it’s not accurate enough and so is likely to cause false positives when the size of the player’s actual sword handle is much bigger. Even though a simple fix is just to compare the distance of handle and the enemy and see if it’s high enough, however the best solution is to use WorldRoot:GetPartsInParts and check if the handle of the sword is touching any base part of the enemy’s character.

local Players = game:GetService("Players")

handle.Touched:Connect(function(hit)
   local enemyCharacter = Players:GetPlayerFromCharacter(hit.Parent)

   if not enemyCharacter then return end

   local enemyHumanoid = enemyCharacter:FindFirstChildWhichIsA("Humanoid")

   if not enemyHumanoid then return end

   local handleOverlapParams = OverlapParams.new()
   handleOverlapParams.FilterDescendantsInstances = {enemyCharacter} 
   handleOverlapParams.FilterType = Enum.RaycastFilterType.Whitelist

    -- Make sure that the handle is AT-LEAST touching any part of the enemy's 
    -- character before we do damage:
    if #workspace:GetPartsInPart(Handle, handleOverlapParams) == 0 then return end

    enemyHumanoid:TakeDamage(15) 
end

Problems with this approach

  • If a player is having a poor frame rate, then the player’s hits will not likely be registered on the server, since the replication frequency of the player’s position to the server will be slowed down.

  • Again, if a player is experiencing high latency, the same problem mentioned above will be faced.

  • Even if both the cases are not a problem, if the player is moving their melee weapon very fast or them selves are moving very fast, then again their hits will not be registered. This is because of the replication hertz at which position and other data is sent to the server from the client (assuming the player has network ownership of their melee weapon and themselves), i.e the player’s approximate frame rate, since most replication data is usually sent every frame.

  • Exploiters can quickly move themselves to the opponent and then kill them, bypassing this check mostly, except in some cases where they move extremely fast enough to the extent their new position has not yet replicated to the server. You may develop an anti exploit to counter this, but other cases include them moving quickly to their opponent, but just not at a very high speed. Thus, mostly bypassing the anti exploit it self! You cannot handle this your self reliably…

  • You may try to account for most of these problems by either increasing the size of the hitbox based off of the player’s ping (player:GetNetworkPing), but again this isn’t reliable since the difference between the client’s data and the server’s data will be very different and far from being at least “closely” synced.

6 Likes
Exploiters are able to trigger .touched events on other players
#34

This was just an example; not something too advanced.

#35

Right, but it is never bad to give advice!

2 Likes
#37

never knew that. thanks!

#38

Oh lol, but is there any way to disable console log in Roblox server, so no one can inject

#40

I just dropped version 2 of the guide!