Yeah, but you don’t want to kick players until you’re confident of this. So normally, you would log when it triggers, and just set the player back to their previous position. Then, if you have time to analyze the data and visualize it on your map, you can see if there are false positives. But don’t kick unless you’re sure, cause that could be a deal breaker for non-cheating players.
3 Likes
I have been thinking about this for a while accually.
Just limit how many times it can trigger per kick.
If it happenes 10 times… They get kicked.
Happenes once give em’ some slack.
1 Like
That doesn’t work. You could have some corner cases where you end up getting false-positives many times in a row. Quantity of detection is no substitute for quality of detection.
Well then how do you detect corners? It does not seem easy.
1 Like
It’s coincidental that literal corners are a problem case here, since I meant “corner case” in the statistical sense, which is a difficult-to-discover failure case requiring lots of fringe values. One thing you can reliably do to detect clipping, is to detect if a character is inside or overlapping a part. This won’t detect teleport exploits where a character instantaneously goes from one side of a wall to the other, but you can catch people who set parts locally to no-collide and walk through them. Detecting teleports is much trickier.
For buildings and restricted areas, I recommend using hidden checkpoints on the server. For example, if you had say, a jewelry shop that people were teleporting into to rob, you could put parts in the doorways that, if not passed through, would invalidate the move from outside to inside. I did something like this in Misfits High’s hedge maze: to get the badge for solving the maze, your character had to pass though 4 points on the known solution path on the server for the solve to count. So you couldn’t just no-clip into the center and get the best time. The points are not exposed to the client, so there was no way for anyone to know that they existed, or where, or how many. We also knew the best possible timed speed run and invalidated faster results from walkspeed hacks.
1 Like
So can I put a small part inside another part, and if the player is touching the part in the part then kick them?
Edit: Its a bit catchy to read sorry
No extra parts needed. Bi-directional raycasts can tell if a player has entered a part (raycasting from prev to current location hits the part, raycast from current to previous with the same part whitelisted does not). This is what I do in my shooter to check if the tip of a gun is inside or entirely through a wall: raycast from the back end of the rifle barrel to the tip, and from tip back. Very easy to know with 2 raycasts exactly the situation and whether or not a shot can be fired.
1 Like
Do you mean the back of the tip of the gun?
I understand everyting else. But do I have to whitelist the “raycast instances”
*Will Raycasts detect each other if they are touching each other?
So basicly raycast from the tip of the player, to the back of the player, to the ‘backtip’ of the player?
I’m confused.
Raycasts only return hits when they hit the outside face of a part, so assuming you mean from all diagonally-opposing corners or opposite faces of the HRP, then if you do it in both directions you’ll pretty reliably detect if the face of another part is passing through the root part, if you make some basic assumptions about the nature of walls.6 total raycasts required. But this won’t handle the case where the root part is entirely inside another part. There are also still ways for the corner of a part to be inside the root part undetected, but it would need to be just poking in in a way that a wall or floor wouldn’t be.
For the gun, I meant from the rear of the barrel to the tip. The raycast is as long as the barrel, right down the center axis. The entire gun and character are on the blacklist. Raycasts aren’t instances or parts, they can’t hit each other. They are just a line segment in world space that you’re doing intersection checks along.
1 Like
A few years ago I attempted something like this.
There were a lot of false positives (specifically on characters with complex collisions)
I have an idea for a noclip detection setup like so (I have yet to build or test this):
- Use GetTouchingParts to find intersecting parts (specifically on HumanoidRootPart) and if they intersect a part apply a strong pushing force towards their old location
- Every x frames (RunService.Heartbeat) follow the player’s path back by x frames or so and by raycasting from point to point (x raycasts at once) you can detect if any of these points pass through a part.
- If they have gone through the wall move them back to their last valid position (before traveling through the wall)
This probably needs to be refined but it’s hopefully a reliable way to prevent noclipping.
By splitting up the raycasts into chunks you’ll cause lag spikes every x frames and a bigger delay to prevent the noclip, but overall you’d be saving more frames for other stuff to happen which gives a much less noticable difference to players.
2 Likes
I will definitly use ^ in my Anti-Noclip Instead of kicking them.
Cool! 
Preventing teleporting and speed hacking is even easier to do by the way… It uses some very simple math and only a few logic checks.
1 Like
Just detect how far a player moved in a second, if the player moves too far in a second, move them back to the position before the anticheat was triggered.
For example: Player moved more than 25 studs a second? Move em’ back. Why not 16 studs you may be asking? Because of false positives. (The network letency / Ping)
1 Like
Just as with rate-limiting, you don’t usually want to work with just one sample either, you should average or leaky bucket this so that a momentary disconnect, lag spike, or lost packet does not register as a teleport just because it exceeded the threshold + tolerance.
2 Likes