There’s a bug with the anti-teleport where if you try swimming in Roblox’s terrain water, it’ll think you’re teleporting and keep sending you back near the ground or activate whatever custom punishment you have.
Edit: Anti-fly seems to detect it as an exploit too but only for a couple seconds or not as much from what i’ve tested.
Another problem I’ve encountered were non-collidable parts, if you have a part that you can go through, wide or thin, it’ll detect it as an exploit. I know this probably has to do with ‘maxShortRangeTeleport’ but it’s a problem that can just be fixed just by whitelisting parts that are non-collidable through I think.
Also, if you go near a moving NPC (or one that follows you), you’ll start getting teleported (in this case I just have it set to the default soft punishment) around the NPC.
would a pcall help so that it does not hang sub code?
I’ll look into it. I believe right now, it checks for the “swimming” state of the humanoid, but that might only be for speed cheating. 
I suspect the fly cheating might be looking through the water as empty space and think they are flying too, I’ll check that.
Hmm, non-collidable parts should be ignored, I’ll try it out to see if it’s getting confused about big ones.
The swim bug (if I am correct) should be an easy fix. Not sure what tricks the teleport on large walk through blocks though.
The NPC issue is unique, I suspect any collidable parts crossing the player humanoidrootpart (probably just client prediction) is triggering it. That one will take some thinking for a solution, hehe. 
I try to avoid it if possible. Right now, having a timeout works for any possible states not coded for it (error wise). Some things you have to use a PCall because there is no other way to avoid a crash, but so far I haven’t encountered anything (yet) that needs it. Either the objects exist to scan or they don’t and just ignored. Hopefully no 3rd state pops up again like it did for the player characters (exist as Not Null in code, but not really when trying to work on the object) if they leave the server at a moment where they don’t exist but the server still thinks they do. Yes, very confusing to encounter this, lol. 
Thanks, I did find a quick workaround for the swim bug by constantly checking if each player has the “swimming” state, and if they do, it’ll give them the fly and teleport exception, and when they’re not in the water, it removes it. However it still detects an “exploit” sometimes when the player gets out of the water, so it’s only handy if you’re using the soft punishment, as they only get teleported for like a second.
The terrain bug is interesting. When you are “in” the water, everything is fine, but when you exit or enter (as you already mentioned), it detects a collision. It seems the “surface” of the water is considered to be “collide-able” for some reason.
I noticed that there is a way to “ignore” water when raycasting, so I think a default of “ignore water” should solve a lot of these issues and I can add a variable to NOT ignore the water if a developer needs it to work the other way, just in case (like maybe lava or something). I’ll do some testing to see if there are any bad side effects of ignoring the water.
I have the issue with the water collision solved for teleport cheating causing a false detection. I thought I needed to have an optional flag for the water collision, but I can’t really find any reason why a developer would want to do this? Since the teleport cheating is usually to go through a solid wall or long distances, I can’t imagine a time when a developers would want to make the surface of the water solid (for teleport cheat purposes). Without the need for an optional flag, the fix can be put in without anyone having to make any configuration changes, it will just work. 
I did a lot of testing of the fly cheating in water and other than 1 false detection when you bounce out of the water, it resets back to 0 pretty fast as you fall back into the water. Unless you have your fly-cheat detection threshold set so low that 1 detection event triggers punishment (the default is 8 detection events), I don’t see it as a game breaking issue, cheat detection wise.
Interestingly enough, the fly-cheat detection does see the water “surface” as ground for a moment if you are close enough to it. I think this could be exploited to “hover” over the water and fly-cheat in a way. I can change it to ignore the water so that “hovering” over the water still counts as fly-cheating to counterattack this. Unless there is a good reason to consider the water surface as “ground”, I don’t see a need to create an optional configuration to do this. So expect this to be changed as well to ignore “water” when doing a fly-cheat scan.
Finally, I was not about to reproduce teleport cheat false detection with really thin or really thick parts that the player walks through. Do you have any examples that I can try to reproduce this with?
I’ve made a service update to this. If you are using the auto-update code version, then your servers are already protected. 
If you prefer the manual update method, I’ve updated the download model at the top. I also found a way to include the auto-updating service mode without setting off the hack detection on Roblox, so for those that want to use this auto-updating service, it will be much easier to setup via the instructions at the top; first post also.
5/11/2024
I’ve been trying this out with my first game (not publicly published yet) and I want to say it’s really impressive. I think it would easily lock out this kind of cheating on a game that wasn’t super heavily physics based.
My game is an obby game and I’ve not yet been able to calibrate things so that I can go through all stages without being zapped by cheat detection while not cheating. More mysteriously, I don’t seem to be able to calibrate it to not go off when dropping from the highest height in the game, even though I set both the falling/floating times to seconds longer than the drop. The teleport cheat starts to go off after a few seconds of falling.
However I think I know why I can’t just get through the obby course with it, and thought I should give some feedback on that. I have lots of obstacles that are set to become unanchored when you touch them (e.g. crumbling paths). The anti-cheat’s debug messages show it’s not detecting player feet touching those parts at any point, and I don’t know how the code works exactly, but I assume it’s because of them going unanchored so fast? So entering one of these crumbling areas, everything looks like an ongoing too-large jump or teleporting or flying to the anti-cheat. I increased ray-casting downwards and around the player’s feet to 10 studs to see if it would register these fast-crumbling parts at all, but it doesn’t.
I can think of a few things that might help.
Starting with the Teleport cheat detection. This basically checks for distances that are too long, say moving more than 100 studs in 0.25 seconds for example and moving through objects that are set to collideable. Since it sounds like you have a big obby with lots of space, you can probably set the max teleport distance to something like 9999 to basically disable it, but the part that checks to make sure they didn’t just walk or teleport “through” a wall will still work to prevent just teleport cheating through obstacles, etc.
The next issue is probably the speed, as a long fall will have the player moving very fast. To allow long falls but stop players from speed cheat running the longer parts, you can disable the Y axis check on the speed cheating detection. This will ignore has fast they fall or move up and only calculate speed based on the XZ axis, which is just running north, south, east, west and ignoring things like up or down stairs.
The fly cheat detection, depending on if you have water to swim through or ladders to climb can get tricky. This and the jump detection is what is casting rays from the feet to the next “collideable” object to detect if the player is standing on something solid.
Feel free to private message me if you want to make sure the details of your obby remain private since you have not released it yet, I’ll be glad to help.
Thanks for the insights! I’ll investigate and then I’ll PM you to let you know how it’s going.
I’ve made a service update to this. If you are using the auto-update code version, then your servers are already protected. Instructions for setting up your game to auto-update with each version release is located at the first post on top.
If you prefer the manual update method, I’ve updated the download model at the top as well. If you want to use the newly added configuration option for anti-fly cheating, this is the easiest way to do it without having to copy/paste service code between versions. 
7/28/2024
Explanation of the new changes to the Anti-Fly Cheat Detection:
Previously, the anti-fly cheat service worked along this logic.
This works in most situations, but recently fierytata has brought up an issue with the logic. If a player is standing on a top of an object for example and that object is “dropped” so that the player is riding the object down at the same rate, it will trigger false detection events. The reason for this can be tracked down to Internet lag. The pictures below help to illustrate.
Here, my player is riding down this object at it drops. From the client perspective, it looks like I am just standing on the platform as it falls down, everything looks normal.
But…because of Internet lag, my character appears to be “floating” down from the perspective of the server.
The server then mistakes this “floating” as fly cheating under the old logic. The raycast is not reaching far enough down to the platform. An easy hack is just to increase the raycast distance set by the developer, but since everyone can experience different levels of lag, they may be floating at difference distances, some higher, some lower. One, catch all setting is kind of messy and could lead to cheaters finding a way to exploit your settings.
What has been changed is what to do when the anti-cheat encounters this, the logic has been updated to work like this.
This allows the developer to give special settings to a player falling and riding an object that is also falling without having to mess with any core “distance” settings for the anti-fly cheat system.
The configuration setting was added to the “KnightmareConfiguration” file under the maxRadiusToObjectDistance section as:
--[[
When a player is floating, this will boost the scan distance to help find
a collideable object underneath in case they are riding down a falling
object at the same rate that the object is falling. Lag can make this
appear to float to the anti-cheat and cause false detections.
Default = 1.5 studs
--]]
boostFloatingDistanceScan = 1.5
If your configuration file is missing this section, the new version will fallback to the default so that you can still get the benefits of it without having to configure it. If you want make sure your local copy is up to date, you can re-download the model and just do a side by side configuration file comparison to sync up the settings. Just copy/pasting this into your configuration file will not work because the new setting is loaded via the “new” version of the configuration file.
Yeah, I hate it when it takes that kind of update… 
But it’s necessary to make sure the service and the configuration are sync in the correct version.
If you don’t need to use this new configuration feature, you don’t have to do anything other than update the service (or auto-update if you use it that way). If your game needs this configuration option to be set to something other than the “default”, then you will need the latest version of the model to get started so you can tweak the new setting.
Hey, KnightMB. I thought I’d point out a few flaws in your anticheat since they’re pretty substantial. I won’t waste any further time, so let’s get into it.
Firstly, State exemption.
You use Humanoid states to check whether the player can be flagged or not, which is not good as the exploiter can simply change their state to the states you’ve whitelisted and bypass both your fly checks and your jump checks.
Secondly, the fly checks.
You run the checks every 0.25 seconds while casting 15,000 stud rays to check if they’re on the ground, which is terrible for performance. A better idea would be to use WorldRoot.BlockCast as it’s a huge improvement from raycasts.
The Velocity check’s got more holes than a Swiss cheese. It can be bypassed by using a “bounce” fly, where you go up and down while still in the air, or by using a “glide” type fly, where you slowly move down.
The air time (float) check can be bypassed by teleporting your character to the ground and back up just before the maximum allowed air time is exceeded. Now you might say the jump cheat checks would detect this, but they can also be bypassed by using the state exemption bypass.
They can be bypassed using the state exemption bypass method mentioned above. (same with jump checks so I’m not going to go into that much depth)
You could improve these fly checks by adding a maximum falling speed that you have to be at to be exempted to prevent certain fly bypasses, for example. Don’t just have a simple air time check. Try to check if their velocity does not equal a normal player’s velocity, and use math instead. Calculus is your best friend in this scenario as it has all the calculations needed.
Another area that needs improvement is your implementation of heat-based detections as it seems that they’re overused in the wrong places. For example, if the player is 10% faster than normal, then start slowly incrementing the heat and don’t update their position.
General issues
You don’t check for CFrame changes on the server, meaning that if the server legitimately tried to change the position of the player via a teleport pad for example, they’d falsely flag.
You don’t check for flinging. Use BasePart.RotVelocity, but preferably BasePart.AssemblyAngularVelocity since RotVelocity is deprecated. Also, make sure to check if the character has a BodyMover inside of it just in case the player doesn’t false flag if the server rightfully adds one as a spin command or something.
And lastly, you need to have proper patches for certain bypasses. Don’t always rely on changing the configuration to “patch” a bypass. In my opinion, this anticheat could use a full rewrite, since it’s too long for such simple and basic checks that could be bypassed faster than a tumbleweed in a dust storm.
Good luck,
– kxr (@xd_xdxdxdxdxddxd), XNX (@XoifailTheGod)
I appreciate the feedback, but I do have to question how it is presented.
The climbing and swimming states are optional and be disabled by the developer. That has come up in discussion here before, but some games need it and some don’t.
The raycast defaults are very short and set by the developer, they are much more efficient than using a 3d blockcast because the math involved is very simple. I’ve done a lot of performance testing since the first release and the entire anti-cheat suite is very CPU efficient.
All of that has been tested before and fails to work against it, depending on how you have it setup for your game.
Again, a lot of theoretical ideas that are harder to do in practice. There are lots of ways to bypass the system when using the defaults, but that’s why it has so many tunable options so developers can dial it in for their own game.
I have looked at such a logic setup before, but after testing, found it too easy to bypass by simply changing the gravity of the player. While the suggestion is a good idea, but it’s already tunable by the developer in many ways to make this unnecessary.
That’s why exceptions where created to address this, so a server could teleport a player and ignore one false detection without punishing the player. Again, this was created and documented for the developers to use in their game.
That is by design since flinging can be used as an exploit bypass. Everything is purposely designed to rely on the client as little as possible and to be as efficient as possible.
We can agree to disagree. 
I’m very confident in my coding skills and while you do bring up a lot of good theoretical issues that can be debated here, what actually gets improvements made is when other developers bring me issues that can be demonstrated and replicated. I can poke an infinite amount of holes in your suggestions or your understanding about how the anti-cheat service works, but my energy is better spent towards improving things for the thousands of people that use this software than trying to tear everything down and start over because someone else doesn’t like how the software development is managed.
As with all things, if you think you can do a better job, there is nothing stopping you from creating your own suite of server-side anti-cheat tools for developers.
Hey again, KnightMB. I truly meant no harm when replying to you, even if I made such statements like “The Velocity check’s got more holes than a Swiss cheese.” or “it’s too long for such simple and basic checks that could be bypassed faster than a tumbleweed in a dust storm.”
That’s not the point. The point is that there’s a bypass in your anticheat and it can be patched very easily by using a different method to check for climbing and swimming. If this is an anticheat service and you’re expecting people to use it, then it’s probably best for it to come working correctly out of the box without having the developer need to manually configure it himself. You might think this is impossible, but it really isn’t.
You’re once again relying on the idea that changing the configuration will “patch” a bypass. This practice is not recommended as there will be times where doing so would not work. And the fact that it doesn’t detect highly blatant cheats from the get-go is a major issue.
If using such a setup has a bypass, then patch it. You’re once again relying on the fact that the configuration can patch everything. If changing the gravity bypasses, use math to determine whether the player is falling according to the server’s real gravity. One of the main points in an anticheat is that if you find a bypass, you patch it. You might say “Why not avoid it completely and have to worry about patching it?”, but that’s when I tell you that you’re wrong because in this scenario, doing what I told you is actually very viable and would open up a lot of other detection opportunities you didn’t even know existed.
I personally didn’t see anything in the code related to exempting people that have had their position changed from the server. You don’t even need to have the developer do it himself, you could just make code that automatically does it because of how simple it is. Using Instance:GetPropertyChangedSignal or Instance.Changed on the CFrame property would fire if a player’s position was changed from the server and only from the server.
I don’t know what you’re talking about. You don’t need the client to check for velocity. You can safely use BasePart.AssemblyAngularVelocity on the server and it won’t do you any harm. If you thought that it didn’t replicate or something, then here I am telling you that it does.
Now with that over, let’s get to some actual bypasses.
Fly bypass.
Just to clarify, I set both “ignoreClimbing” and “ignoreSwimming” to true in the configuration, so what you’re seeing is a raw bypass with no hacky methods. Even if you check for velocity, by using CFrame to control the character instead of using Roblox’s normal velocity controller, it can cause the values to get messed up, which makes me able to move up and down without triggering any velocity checks. This allows me to teleport to the ground and back up to bypass the air time check with no issues.
Speed bypass. (default configuration)
By using a “pulse” speed, I can still go really fast without allowing the heat to go up. As you can see, I move substantially faster than normal.
Speed bypass. (strict configuration)
From what you can see in the video, I set “maxPlayerSpeed” to 14, and “maxSpeedCheatDetects” to 8, making it pretty strict to the point where even walking normally would flag. This is to show you how you can still bypass even if you change the configuration. I hope this will make you understand why relying on the configuration to patch bypasses is not good.
The script I used to bypass here can literally be detected reliably on the first flag at the slowest speed you could think of until it’s not even faster by even 2% anymore, with no false flags, of course. This is why you need to revamp your checks.
I really hope you take my words seriously and think about this for a moment. You can do what you wish in the end.
Best regards,
– kxr (@xd_xdxdxdxdxddxd), XNX (@XoifailTheGod)
Im probably very late to this or maybe someone already said this but for yoyo fighting you can temporarily set networkownership of player to nil if they flag a lot. Then set it back to normal after few seconds
When I read your first post of feedback, I could not decipher your intent because a lot of your feedback had a lot of incorrect assumptions about how the anti-cheat works and a lot of passive aggressive complaints about the implementation. When I watched the video, I spotted that the configuration you used was not the same one you just posted about above. Regardless…
I believe you wouldn’t have taken the time to write all of this feedback, perform test and even make videos to demonstrate if you were trying to troll the topic or myself.
I’ll break up my replies into blocks so that it keeps things focused about each of your inputs.
Speed Cheat by Just Cheating a Little:
Your video demonstrates what was discussed last year about the same thing. If you speed cheat a little, you can game the developer settings. Your video is a good example of Internet lag for a lot of players. It is possible to make the settings so strict of course that your example bypass would not work, just set the “maxSpeedCheatDetects” to 1 and prepare to be annoyed.
The problem with doing this is that developers don’t want to annoy the non-cheating players. Any player that experiences just a little lag with it set that strict is going to rubber-band around the whole map and not understand why. They will blame the developer and complain to them about it.
The developer has to make a balance between stopping as much cheating as possible and not punishing good players with false detections. So while I understand where your heart is about how good or bad this anti-cheat detection is, you must understand that a lot of the settings are for the purposes of balance for the developer.
As I always say, this anti-cheat isn’t meant to be flawless, it’s meant to be good and tunable for the developer. I could write a flawless anti-cheat that only works under the most ideal conditions, but it would be useless in a real public game where all your players are using different devices, running at different speeds with various levels of bandwidth and lag.
I get where your heart 
is, I really do!
My inbox is filled up every week with feedback from hundreds of developers asking questions, asking for help, asking for new features, asking for new configuration options, etc. You are only the 100th person to point out that the default speed settings are not strict enough under certain test conditions, so I understand.
I’ve made a service update today. 
If you are using the auto-update code version, then your servers are already protected. Instructions for setting up your game to auto-update with each version release is located at the first post on top.
If you prefer the manual update method, I’ve updated the download model at the top as well. Hopefully one day Roblox will give us the ability to release “public” packages to make updating easier with patching, but until then I use the hacky method.
8/1/2024
Explanation of the new GUI Window Based Debug:
For over a year now, using the debug settings to get an internal view of what the anti-cheat system was observing from the players consisted of trying to watch text rapidly scroll by in the Studio output window.
After my last update and having to use a lot of debug output to solve the issues, I realized that the developers needed a better way to tweak their settings. I’ve created a very simple GUI window that gives you the same information that the output window did, but instead of rapidly scrolling copies, you get real-time data that is better organized. No more having to scroll the output window to find something important that you needed to watch.
An example of the new Debug GUI:
Even better, it supports multiple players, so if you want to do a team test with other players, you can get debug data on everyone at once.
Finally, if you don’t like the default text color, text size or even how big the debug Window itself is, well you can customize all of this in the configuration file in a new “global settings” section near the bottom.
As always, thanks to all the developers that provide valuable feedback and resources for me to work with!
I’ve written a developers guide for nearly all of the configuration settings to this service in the tutorial section of the forum here: