Weapon AntiCheat

Hello, I am currently making a gun system and there seems to be a MAJOR problem, is there a way I can do something about this? This took me not even a minute to setup this in the console and it could easily ruin the game. I already have a distance check but I don’t want to add too many checks as it could make the server take too long to fire the weapon.


Any help will be very much appreciated

2 Likes

So from what I am seeing, it is a firerate exploit. To prevent firerate exploits, you have a max amount of bullets that can be fired in a minute. Check how many bullets the gun can shoot in a minute vs how much the client shot in a minute. if its a crazy amount, kick the player or whatever. Another way you can protect this is by checking the firerate of the gun on the server vs the amount of remote requests being sent, if its firing more bullet events than the firerate speed, then start to ignore future bullets until the previous bullets register. You also can protect your env on the client to prevent manipulation of gun data.

2 Likes

Can you clarify more on I can protect my env on the client to prevent gun data manipulation?

I’m not sure how your game functions, or more specifically, the code in the remote event

Since your using remote events I would see about adding a type of debounce where if you fire it x amount of times, it removes future requests. Some examples may be: if you fire it more then 100 times in 3 seconds, If you fire correctly at someone 50 times in 10 seconds, if a player has damaged another player without missing a shot in the last 20 shots etc.

These are some examples of a firerate prevent ideas, to prevent abuse. Now keep in mind that with things like this it could catch innocent people which is why you might want to ignore the bullet then kick them. These are just some ideas

1 Like

You shouldn’t rely on the client env check for security as it could be bypassed. But you can request from the server ur gun data and check if its the same. Or have some hook detections on ur gun data to stop it.

1 Like

Originally, it was using Raycast on both the client and server to check if they were the same, that could also be bypassed easily as it requires atleast something from the client to see where the raycast should land. If I were to just use the server for where the gun should shoot, there’s going to be a delay in the bullets which I don’t want but even again, that requires something from the client. We’ll have moderators so any aimbotters can be banned, but I just want a simple check to see if something is off and not let the bullet to be fired. Perhaps I can maybe just do simple checks such as what was their firerate for the past few seconds, etc which is what @OfficialPogCat mentioned. I understand there’s not much I can do, but there has to be atleast something to prevent remote spamming, etc.

Also I am seeing you send a lot of data from the client to the server in your remote event. Again I don’t know how your remote event is set up, But I would try to keep as much as you could server side. For example, do you need to send the tool from the client, or could you use the server a figure it out based on the provided player argument?

Basically what I am trying to say is if you can keep it server side, or you can figure it out on the server, do it on the server and don’t have the client send that information.

You don’t need an “anticheat” for this, just make sure the client is never telling the server something because the client can never be trusted. The client should only ever request things from the server, and the server needs to decide if the request is okay or not. This is called sanity checking.

The tool property is to see if the tool exists that they’re firing, and is actually in the players character, that’s just another one of the checks. The only thing the client is really being used for is what was hit which is from mouse.Target, startPos which is the tools barrel position which is checked on the server, if its different then it doesn’t fire and the hitPos is mouse.hit.p which is checked if the pos is close to the humanoidrootpart of the target

Yes, and I also always say never trust the client with anything, but this is a TPS gun system, what else am I supposed to do? It’s using the mouses hit positions, etc, I can’t get that on the server so the client must tell the server that. It’s not like a FPS system which uses raycasting on the server.

Sorry, I didn’t read the post thoroughly.

From the video you sent, it looks like you’re worried about aimbotters. Since you’re using hitscan for your bullets (cast 1 raycast, bullet travels instantly), this will be a problem.

You could do sanity checks such as:

  • Check if the clients hit position is too close the the origin of the limb (meaning they are locking onto the limb)
  • Check the speed of the hit player and decide whether its reasonable they were shot while moving so fast

There are probably countless others, but if you want to think about switching over a projectile based system, it would make it much harder for hackers to use aimbot because they would have to predict their shots. There are modules like FastCast you could use, but that still trusts the client too much.

I suggest using the module SecureCast, it is projectle based, does raycasting serversided, has ping compensation, etc. I’m using a modified version of it inside of my project and it works pretty well.

If you’re interested in switching heres a link to the module, but if you’d like to stick to hitscan based projectiles I’d be happy to help with that more. Link: SecureCast, server-authoritative projectiles with lag compensation, multi-threading and more!

2 Likes

Thank you for your help, I will definitely check into it. It’s also not just aimbot I’m worried about, I’m also worried about somebody spamming the remote so fast and make the server/other players lag.

This is pretty easy to check on the server.

It may look something like this (just example code):

local LastShot = 0
local DelayTime = 0.2

local function ShootBullet()
 if os.clock() - LastShot < DelayTime then -- If the time since we last shot is less than DelayTime then stop here
  return
 else
  LastShot = os.clock() -- Set the last time we shot to right now
 end

 -- server sided stuff here

end

Yes I just added this

	local myTick = ticks[plr]
	if myTick and tick() - myTick < mimFirerate then
		return
	end
	ticks[plr] = tick()
1 Like

You can technically stop remote spamming by checking how many times the player fires the remote in x time, which I clearly stated in my init post which I think you completely overlooked.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.