If you are using the default settings without any tuning, that’s possible to get a lot of false detection events since it’s unknown what settings a developers wants to use. That’s why I don’t enable it by default when they download the model. All the default triggers simply soft punish the player, nothing in the code kicks them from the game. It’s easy to set it up that way, but the default punishments either send them back before the cheat was detected (Speed), send to the ground (Fly), send them back before a teleport was detected (other side of wall, etc.), or sap their linear velocity (Jump).
That would only work once and then the server would force-teleport you back again to the previous recorded location. Your player would be stuck in a yo-yo effect fighting with the server. I’ve seen this happen in public servers where exploiters were very active and everyone knew they were cheating because they got stuck in a yo-yo effect and they even admitted to it.
Speed cheat detection has an lower bound of usefulness because if someone is just CFrame jumping around, that’s not really a speed cheat, but more of a teleport cheat. The Teleport cheat detection is better at stopping those types of exploiters.
As an example, if a developer knows that no player will ever move faster than the 50 studs / second in their game, trying to catch a player cheating with a setting of 52 or 53 is easier than trying to catch a player cheating with 1,000 because of the vast distance they can travel between the time the server measures their last position and the current position to calculate speed. That’s why a developer would then tune in the teleport cheat settings to not worry about players moving at insane speeds. The only alternative would be to set the speed detection so low that players that lag even a little would set off the detection and get annoyed by the penalties. The detection system has to be flexible enough for live and busy public servers without the developer getting a stream of complaints about being rubber-band around by the speed cheat system and false detections.
If you did what I did you would know that it teleports you every time the server attempts to bring you back to the ground, not a yoyo effect. It takes 1 minute maximum to set this up.
Also, I am using Speed and Flight detection with other default values.
Even if a dev was smart about it by setting the maximum WalkSpeed and such, an exploiter could just Tween their characters CFrame very slowly and it will still be replicated to the server and if the anticheat detects that he’s in the air, he also has another script running in the background that detects that and then brings him back
Then I’m not really sure what you are trying to demonstrate then? It would help to focus on one thing at a time because trying to mix everything in is where the confusion is. I assumed this was about speed detection, but now it’s fly detection too?
We can have a theoretical debate about it all week, but until I can see some real evidence of what you are trying to demonstrate, there isn’t much I can do about it. Even your screenshot seems to indicate that speed detection is tracking speed and setting off the speed cheat trigger with exceptions that only happen when you manually over-ride the server to ignore the player.
I think I finally understand what you are referring to. There was a lot of confusion earlier because I was just focused on the “speed” cheat part of the detection, but you are referring to other detection modules interfering with each other. So, basically using the fly cheat detection to interfere with the speed cheat detection as an example. That is something that was in the works, but I did not have time to examine it fully yet, so I will do that now that I have the free time and come up with a better solution than the one it’s currently using.
I used this module in a public free UGC limited event and just want to sing highly of how well this module prevented exploits, we could see exploiters actively getting rubber-banded backwards and overall didn’t receive a singular report of a blatent exploiter retrieving the limited item. The only asks that I would have for possible new features are the following:
the ability to add ‘custom punishments’ on top of teleporting back, currently you can only have one or the other however it would be ideal if we could easily stack our custom punishment on top of the rubber-banding that exists by default. We had to code this in for our limited event so we could deny awarding the limited to users who were recently caught teleport hacking.
the ability to ensure that players only get rubber-banded onto a solid floor, we had a small jumping section in our event and a lot of players reported getting falsely detected and teleported into the middle of the jump, killing them unfairly. Ideally, there should be an option that only sets the ‘last position’ variable while the player is on a solid floor to avoid these cases.
The latest update is a fix to how multiple cheats being active at once are handled. Back in July of last year, I added temporary exceptions when multiple checks were active so they would not fight with each other if a player triggered two cheats at the same time. This was to solve a permanent rubber-band effect on the player if by exploit (or false detection) they triggered speed and teleport cheats at the same time. The two detection’s would fight with each other on the player forever and leave the player stuck in rubber-band limbo.
As was pointed out, those exceptions can actually be used as a kind of loop-hole for properly timed cheating. So if a player teleport cheats, the server sends them back to the previous location, but also reset the “speed” cheating counter on the player as a precaution (so speed detection didn’t think they speed cheated when they were force teleported back and teleport them yet to another location). An exploiter could use that as a way to speed cheat at the expense of teleport cheating.
So… basically had to rework everything with that in mind.
The way the new system works is like this. Instead of granting an exception, it simply syncs up the other cheat detection. If a player does a teleport cheat (through a wall, way up in the air, etc.), the server sends them back to the original location and simply updates the speed detection to that new location. If your server had a speed limit of 20 (example) and the player is running at 100 and using a “teleport exploit” to reset that speed counter with an exception, this will no longer work. Instead, the speed counter will just continue as it did using the new location you were sent to (via teleport soft punishment) as part of the next update.
What does this change mean?
It means it’s possible again for a player to get stuck in a rubber-band effect if multiple cheats are activated at the same time, but it makes far less likely to happen by false detection. Even if a rubber-band loop is created, eventually it will stop. I was about to test that by just going crazy with cheats and trying to get a rubber-band loop to happen. I was about to get it a few times but only when using just insane cheat values like jump power 1000, speed 1000, something that players will probably never encounter by accident in a game by lag for example.
What does a developer need to do with this update?
If you are using the auto-update service, it will load the latest service version directly from Roblox through auto-updates. If you prefer the manual method, you can download the model again and simply replace the “KnightmareAntiCheatService” file with the newer one, no configuration changes needed. Keep in mind that if you are using the auto-update version, you still have the older version as a fall-back locally that would need to be updated eventually.
Thanks, I appreciate the positive feedback! As I always say my goal is have some good basic cheat detection with a lot of tunable options for developers.
It is possible to rework it that way, but I wanted to make sure the developers had a lot of flexibility after the cheater is detected. For the 1st request you listed, you can technically have that happen in the custom punishment with this code below. Anything you want to do the player afterwards will work and you won’t have to worry about any future updates breaking your customized form of justice. This just does the same thing the anti-cheat service does, just in a separate location that you can customize for anything else you need.
-- This is passed the Player Object and their last Position before the current Position
-- that set off the threshold cheat detection.
if oLastPlayerPosition then
local oPlayerCharacter = oPlayer.Character or oPlayer.CharacterAdded:Wait()
if oPlayerCharacter then
local oHumanoidRootPart = oPlayerCharacter:FindFirstChild("HumanoidRootPart")
if oHumanoidRootPart then
oHumanoidRootPart.CFrame = CFrame.new(oLastPlayerPosition)
end
end
end
The 2nd request, I’ll need more info to figure out the issue. As the player was jumping across, it teleported them back with no velocity, so they basically just fell back down? Would you suspect it was a speed related issue or just a short teleport violation?
I forgot to mention, I’ll add that to the feature list for the future. Adding a configuration option to do both “default” and “custom” punishment for cheaters should be easy enough, just need to test it against the current release to make sure it doesn’t break anyone’s game using an older version configuration.
The last valid location request, that could be another configuration option for the jumping and/or fly cheat detection so if someone decides to float out across a long jump, it sends them back to the last “ground” location instead of straight down to the floor of whatever they are floating over. Could also work on the jump cheat detection, send them back to where-ever the last valid “ground” location was.
Added new configuration setting for punishment settings. Before, you only had true
or false settings which used a default soft punishment or a custom punishment set by
the developer. Now you can set a “both” setting that will do the the soft punishment
and custom punishment in order.
Added new configuration setting for Fly Cheat Detection ‘recordFlyGroundPosition’
that will record the position of where the player is standing on a solid object before
they were detected in the air. If this setting is set to true, the soft punishment will
teleport the player to this previous position instead of straight down to the ground. It
will also pass the last valid ground position to the custom punishment module if developers
want to further expand on the player punishment.
More optimizations because, well I like fast code.
It’s server based only, so it does nothing to or for the client. This only protects the server from the client in regards to sending cheat information such as speed cheat, flying cheat, teleporting (through walls, long distances, etc.) and finally jumping (caps the player jump height). It will have no effect on client cheats that basically copy the memory cache sent to the client from the server.
for i,v in player.Character:GetDescendants() do
if v:IsA("Basepart")==false or v:CanSetNetworkOwnership()==false then
continue
end
v:SetNetworkOwner(nil)
end
There is a way to hack this in so that a player is attached to an object under server network ownership, but it’s too difficult to control the player this way as the delays in movement feel very unnatural. Even with a really low ping, I don’t think players would want to play this way as it’s akin to when we played multi-player back in the 1990s where player movement didn’t use client prediction yet. Anything other than simple movements made it really difficult to time jumps and use items or weapons. Anyone that remembers playing Quake 1 back in the day over dial-up modem will know what I’m talking about.
You are wrong and my code works it just delays your movement
Im not doing any hacks its just a simple SetNetworkOwner(nil) and it does exactly work
I suggest that once you detected the player SetNetworkOwner(nil) teleport them back after setting networkownership then wait like 5 seconds and change it back to SetNetworkOwner(player)
The only part of the player model this works on is the HumanoidRootPart, I did experiment on this years ago and was not satisfied with the results, especially the delayed inputs that made it unplayable even on a low ping to the server.
The server has to keep applying this because it will be reset every time the player has a humanoid state change, be it from spawn, death, switching items, etc. That makes it exploitable by the client, so that’s why I never did anything else with it.
Since exploits are patched and I have yet to test your proposed solution, I do, however, have a hunch it won’t work since it’ll reset the network ownership back to the player. You’ll be breaking the built-in movement system if that’s done.
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.
3/25/2024
Changed all player character object calls to use a 5 second wait-timeout because there is a rare chance for a player to disconnect from a server and time it just right so that it hangs the wait event on the player character itself. This would then hang the sub-code that checks the characters and thus hang all the cheat detection.
I was about to test that by just going crazy with cheats and trying to get a rubber-band loop to happen. I was about to get it a few times but only when using just insane cheat values like jump power 1000, speed 1000, something that players will probably never encounter by accident in a game by lag for example.
This just does the same thing the anti-cheat service does, just in a separate location that you can customize for anything else you need.
