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.
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.
My latest analytics now show that the Knightmare Anti-Cheat Service is now active on over +10 Million Roblox Servers daily. It fills me with great joy that so many developers are now integrating my anti-cheat service into their games and all the crying exploit players that spam my inbox with complaints.
11/26/2024
Changing Player Detection Ignore settings was not clearing previous data readings.
Jump Distance Debug info would remain active when Player was set to be ignored by the Jump anti-cheat service.
Explanation of recent changes:
Both of these are minor updates (code wise), but have useful reasons for the change.
The first change is how ignoring players works. Normally, when you ignore a player for anti-cheat scanning, it usually applied for development or admin reasons. Many developers are finding this useful to create a “time-based” type of ignore in their games instead of just a one-off setting. A developer might want to ignore a single player for “Teleport” cheating for a few seconds and then want to turn it back on because a one-time exception is not enough. The issue before existed that when you “turn off” the cheat detection for that single player, the anti-cheat service still had the original data (location scans) in memory. When you turn it back on, the anti-cheat service would think the player “cheated” based of those old scans since the player has probably moved since then to somewhere else. The new behavior is to clear all “scan data” associated with the player that you disable scanning on. This way, when you turn it back on, it’s treated like a “new” player that just entered your game instead of one that seems to have moved beyond your set cheating limits.
The last change is a minor debugging output issue. The Jump Distance Debug output would remain on for said player after you disabled scanning on that player. This change simply fixes that minor issue.
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.
11/30/2024
Clock Drift timeouts now set for most scanning services. Speed & Jump cheat scanning have a 1000 ms timeout and Teleport cheat scanning has a 300 ms timeout. When these timeouts are exceeded by the server, it resets scanning on the player. This prevents a server overload from creating false positives during cheat detection.
Custom Punishment for Teleport Cheat Detection now passes the Object Hit during the scan to this function for further use by the developer.
Explanation of recent changes:
Roblox Servers normally run at 60 FPS, but because they get busy running your game, the speeds can drop a little or a lot. These drops in speed affect the timing of anti-cheat scans and thus the reason that a clock drift variable is used to account for this. Two issues can arise from this, one that is beyond the control of the developer and the other is within their control.
When Roblox itself is having service issues and your game is suffering a massive dip in speed, the clock drift can only help so much. This is why a timeout has been added. When your game server has been slowed down so much that the anti-cheat service can’t even get 1 scan in a timely fashion, it will basically reset and ignore that player until the server speed is able to return to normal.
Otherwise, the long delays in scanning means a player can create false positives due to their client still running at full speed. This is really apparent on Teleport Cheat scanning because a player can run around a corner far away and if the next scan takes to long, it will think the player must have cheated through the wall to get that far way.
On the other hand, if Roblox is NOT having server issues and your server is overloaded due to something in your game going out of control and eating all your system speed, the same thing can happen. At least in this example, the developer has a way to fix this. But, this also means this change will protect your game from this accidental run-away resource usage as well.
Very nice work. This one actually doesn’t just detect basic things and blindly not trust things. I like how it is also still getting supported (at least it looks it).
Just want to say this works really well for car games however you do need to increase the minimum teleport studs from 1 depending on how your cars move.
For example the template race cars that jiggle about exceed it to around 6-7 studs maybe slightly more.
This can easily be fixed by increasing the studs limit however I feel there could possibly be a way to change this or make it slightly more lenient for other things that the player controls but isn’t the player without having to increase the whole limit.
I will provide a video below displaying what I mean.
Other than that, this is a very very good and well made framework and happy to see the developer is maintaining it too even if it isn’t very frequently!
Currently, updates are small steps when optimizing and new features are usually defaulted to off because of the sheer number of games using it now, a large chunk of all Roblox games. I also provided help (usually via my contact inbox or other e-mail) to developers to integrate it with their game.
Roblox, in the near future, is suppose to be integrating these features directly into the game engine and Studio. I’m not sure though how tunable it will be, will it just be an on/off switch, etc. Until that time, I’ll continue to support this as a important tool for developers. While the world of cheats and exploits is interesting, I do get why they want to spend as little time as possible on the subject. They want more time to work on their own games, I understand completely.
Sounds like a feature request
The issue with using maxShortRangeTeleport is the increase in vehicle speed increases the distance between scans until you start to get false detection events again unless you set a really high number that negates it basically, like 9999.
I’m sure a more elegant and less hackish solution could be created for developers.
The first thing that comes to mind is a way to tag the vehicle to be ignored as an object for cheat scanning. I’ll do some research on the most efficient way to handle this. Just setting some ignore attribute on every possible vehicle part would very tedious for the developer and just a bit overkill for the solution. It would be better if you could just tag the vehicle model itself to be ignored and have it automatically apply to all of its parts. It sounds simple enough, but trying to make it work in the most generic way possible and as fast as possible would be the goal I think. Hopefully some models don’t have tons of levels within levels of parts to speed up scanning, etc.