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
Added the ignore water option to all ray-casting checks. This prevents false detection
when the player passes through the terrain water surface for Teleport and Fly cheat
detection scans. This will also prevent Fly cheating by hovering at just the right
height above a water surface.
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.
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.
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
Updated Raycast Distance Limits to 15,000 as per new Roblox Engine Updates.
Added new anti-fly cheat configuration option for ‘boostFloatingDistanceScan’ that will
increase the raycast range for players falling while the anti-fly cheat detection is active.
This can help solve issues of players riding a falling object where lag can cause a slight
floating effect that causes a false detection of the anti-fly cheat system.
Developers not using this option will still benefit from a fall-back system that will use
the default settings underneath the falling player and the object they are riding on.
Added anti-fly cheat debug output for a ‘Floating Timer’ to give developers a reading of
the current amount of the time the anti-fly cheat thinks the player has been floating in the
air to help in further tweak settings during testing.
Added rounding to all debug output to make reading numbers easier.
Explanation of the new changes to the Anti-Fly Cheat Detection:
Previously, the anti-fly cheat service worked along this logic.
Raycast under the player and look for a “collideable” object to stand on.
If no object is detected within the range the developer has set, assume the player is in the air.
If the player is in the air, check the velocity to see if it seems the player is falling with the range speed the developer has set.
If the player is falling, measure how long they have been falling. Once the time limit that the developer has set is exceeded, assume the player has been up the in air for too long.
Start a counter of how many “fly cheat detections” must take place before it is assumed that the player is using a fly cheat in some way, also set by the developer.
Once the maximum number of fly cheat detections are exceeded, act on the player in some way, as set by the developer.
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.
If the player is falling, measure how long they have been falling. Once the time limit that the developer has set is exceeded, use a new configuration setting that performs another raycast with the distance boosted by the developer setting. This boosted distance raycast is a final attempt to find an object falling under the player at the same rate. If an object is found that the player could stand on if they both stopped falling, then consider it NOT a flying cheat.
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.
Here are a few reasons as to why they’re not good:
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.
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.
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
Changed Debugging Output to display in-game via a simple window GUI, making it easier
for developers to follow what is going on internally for the anti-cheat when testing
and tuning settings for their game. This should help bring sanity back to the output window.
The configuration file now contains a ‘Global Settings’ section near the bottom where
a developer can customize the debug GUI window text color and size along with the
window size dimensions.
A (1) Second Delay was added to the Jump Cheat Temporary Exception to avoid sapping really
long jumps by accident.
Climbing scans now check that a player in the climbing state has either the hands or feet
near enough to a collide-able object to really be climbing.
Swimming scans now check that a player in the swimming state is really inside a Terrain
Water cell. This only works with Roblox Terrain Water.
Added math.abs conversion to filter hackers using account IDs with negative numbers
which can crash the anti-cheat system.
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!
To me, this is such an important aspect to anti-cheats. My general philosophy with them is to automate blocking the blatant stuff. Anything more nuanced can be dealt with manually. Also it is really nice to see the updates and responding to potential improvements in detail. Shows you care, so thank you for your work.
I’ve made a minor 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/3/2024
Added FPS selector to Debug Window. You can control how fast the client is processing
the debug data from the server. The max speed is 5 FPS and the lowest is 0 FPS that
will freeze debug data processing.
This only affects the client, not the server. A large amount of debug data can be generated when testing with a lot of players, which might slow some older mobile devices to a crawl. This allows you to slow down the refresh speed to your client and reclaim some device speed, or even turn it off with the 0 setting if the mobile device is struggling even at the lowest setting of 1 FPS.
The new Debug Window will look like this. The text color will copy whatever you have set for the main debug window itself.
Another 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.
8/17/2024
Added new configuration option for Teleport Anti-cheat to ignore other players during scans for collideable objects. This is useful for games where players are able to move through each other by design.
Updated Teleport Anti-cheat detection to perform additional scans from the hands and feet to check for colliedable objects. This helps to cut down on false detection events when players are moving around objects smaller than the player.
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.
9/22/2024
Reduced WaitForChild time on the Character Model from 5 Seconds to 1 Second since scans are done 4 times per second, waiting longer is not really necessary.
When a Teleport Cheat is detected and the player is sent back to the last location before the event, their linear velocity is sapped to 0. This helps to stop players from getting caught in a mid-air loop where they are falling so fast, they keep triggering the teleport cheat thus never reaching the bottom of a long fall.
Explanation of recent changes:
The first change of reducing the WaitForChild timeout for the Character Model is simply for efficiency reasons. When the player falls into a pit or some other way that destroys the character model, that leaves nothing to scan, so that player can be skipped until a valid Character Model is available for scanning. A sneaky player could technically hang their scanning routine by creating an infinite wait on the character model by leaving the server at just the right moment after their own character model was destroyed in-game and then returning. So the default timeout was used (5 seconds) to combat this type of direct attack on the anti-cheat service. Since scanning is done 4 times per second (not 5 seconds), the extra wait time isn’t really necessary to combat this type of exploit.
The second update that saps the linear velocity of a player during a teleport cheat is to help developers with unique case where a (non-cheating) player is falling for a long distance and the teleport cheat detection will see this high rate of speed as a teleport cheat and attempt to force-teleport them back up in the air. The issue is that the momentum of the player is the same and thus gravity will keep accelerating the player faster and faster.
To the point where they get stuck in teleport cheat loop as per this example video I made below. In this example, I set the max teleport distance super low to trigger it with only a short falling distance, but the same can happen anywhere in a game map where the player can fall so far and so fast as to create a false teleport cheat event.
What has changed is that now upon a teleport cheat event detected, when the player is force teleported back, it also saps any linear velocity. This will allow the player to actually reach the bottom of a fall (or pit) without being stuck forever in the air. It’s not a perfect solution, but it can help developers having issues because of this without having to create some type of workaround.
The most useful being for Large Open Map Obby developers where they want to prevent cheaters from teleporting check point to check point, but don’t want to put up invisible walls or death boxes underneath or through-out the whole map.
Example video using the same Teleport Cheat settings but with the New Update, how the falling player will be treated. At least now, they can reach the bottom without getting stuck forever.
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.
10/2/2024
Minor Syntax Service update to keep it current with Roblox Code Etiquette.
Tracer Lines added to Teleport Debug for better Visual Tuning of anti-cheat service.
Added additional “maxShortRangeTeleport” check to better filter false events that trigger when a player moves around a sharp corner really fast.
Explanation of recent changes:
This is a syntax update on using services in Roblox via their recommended code etiquette. It’s just how a developer assigns an object to the service without using shorthand.
This update will be very useful for Obby Developers (or anyone else really) as it gives visual tracers in-game when you enable debugging for the Teleport anti-cheat services. The tracers stay for 30 seconds so as not to pollute your world if you are setting off a lot of cheat detection events on purpose.
This update helps Obby developers where players jumping or running around sharp corners triggers a false teleport cheat detection event. This update takes the current maxShortRangeTeleport and applies an additional check to the collide-able object by checking the distance where the “hit” takes place on that specific object. A player that is right against an object and moves around a sharp enough corner fast enough can create a collision of the raycheck because of the distance the player can cover between scans. The additional check simply looks at where the player was during the last scan, how much distance was between the player and the hit point on the object and if that distance is less than the developer maxShortRangeTeleport setting. This distance should be less than the distance of the two scans already, so logically, if the player was below this threshold, it was more likely because the player “moved” around the object and not directly through it. It’s not a perfect solution, but it helps a lot with false detection events in testing. It also gives more power to the maxShortRangeTeleport setting to help reduce false events.
Here are some example pictures below of the tracer lines:
My character clipped the side of this object and triggered a possible cheat detection. The tracers show where the anti-cheat was finding a collision via the yellow lines, the green line is where it found a path without a collision and considered it a false positive without punishing the player.
This was a teleport exception, so it colors it green. It still traces out the path to show the developer where the exception was allowed.
This is an active teleport cheat detected with the red line showing the first detection point, the yellow lines are where it tried to peak around the collisions with the head, hands and feet but still found no clear path, so it was considered a valid teleport cheat through a collide-able object.
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.
10/11/2024
Clock Drift intergrated into Teleport Cheat Detection for more accurate measurements against the developer set maxShortRangeTeleport and maxLongRangeTeleport when the server speed is being affected by extreme load or external issues with Roblox.
Explanation of recent changes:
When the server is scanning, lag affects the players in different ways. What happens when the server itself is having speed issues? The recent Roblox issues was a good test case for me. Server speed fluctuates all the time and Clock Drift is already part of the Speed and Fly anti-cheat calculations because they deal with small distance measurements that can be affected by this.
The benefit is that during service outages, this stabilizes the calculations so that players are not unfairly punished because the server is just running really slow. Teleport cheat detection was left out since it was mainly checking to see if a player was just appearing behind collide-able objects via cheating. The distance checks were mainly for blatant cheating, so errors in those calculations didn’t affect them much if it was off by a 2 or 3 studs.
With the increase of Obby Developers using the anti-cheat (by a lot actually now that I can see download stats again for the anti-cheat service ), these precision errors in distance are becoming more of an issue for them. All the more reason to increase the accuracy of the Teleport Distance checking by integrating Clock Drift.
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.
10/22/2024
Additional Teleport Cheat detection from hands and feet use original collision distance plus one stud distance to avoid short distance checks below the Roblox precision limit. Anything under the precision limit in Roblox resulted in a failed raycast that could be exploited to bypass Teleport cheat detection.
Teleport Cheat detection last valid position cool down added due to precision errors in position data. Roblox precision is limited to the thousandths decimal. With enough time and patience, one could eventually break through Teleport cheat detection because of these rounding errors.
Explanation of recent changes:
Both of these updates come from open discussion elsewhere about how to get around the Knightmare Anti-Cheat service. They probably should have not made it so easy for me to find it.
Anyway, I was about to reproduce the issues myself, so getting a fix together only took a few hours of testing.
Both issues steam from the precision limits in Roblox. When it comes to distances and part sizes, small numbers only make so much sense to a point. For that reason, Roblox limits part sizes to the thousandths decimal of precision. It makes sense from a technical stand point. From a cheaters perspective, this can be exploited in rather “creative” ways.
The first issue was short distance raycast. If you decrease the raycast distance small enough, you basically don’t get a raycast. Since these are important for Teleport Cheat detection, what exploiters were doing was getting a character as close as possible to a wall for example and with enough time, one could eventually get the anti-cheat service to make raycast so small, they fail automatically. Especially from the hands or feet for example. This allowed a “gradual” way to get through a wall or other solid object without the Teleport Cheat detection generating an event to check against.
This leads to issue number two, which was after a teleport cheat was detected and the player was forced back, with enough movement persistence, the variable that records the last valid position for the player could be chipped away at until it was moved close enough to said wall to get inside of it. That would allow the exploiting player to then get through the wall without being detected.
Both of these require some very fined tuned exploiting scripts to work in chosen games, they don’t usually work in any game being protected without some tuning first. Both of the changes I’ve made basically eliminate both of these by rounding all the precision up by 1 stud regardless and putting a cool down on last valid position updates when a player is detected as constantly trying to teleport cheat to eliminate the precision drift.
is, I really do! 
Server speed fluctuates all the time and Clock Drift is already part of the Speed and Fly anti-cheat calculations because they deal with small distance measurements that can be affected by this.