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.
1/14/2025
Minor code tweaks with default configuration file & settings info updated.
Fix Jump Cheat detection debug info could get stuck on debug screen.
Increase debug info real-time information clearing delay.
Changed Debug Output to avoid too many update signals creating excessive output updates for load heavy Clients.
Added Scans Per Second to Debug Info to show how fast the server is able to scan all the players.
New boolean attribute “KM_MESHPART_SCAN_POINT” set to true, in Studio or live via server script on any Meshpart Children Objects under the Player Model. This can provide additional scan points for Teleport, Fly, and Jump anti-cheat scanning for custom player models.
Speed & Jump cheat detection will reset to default dev settings if turned on/off for the same player, over-writing any previous settings changed before such as max speed or max jump height. The new behavior will leave any previous default setting as-is if they already exist when initializing the scan data on the player when enabled again.
Explanation of recent changes:
Updating configuration file information about new default settings and features available for new setups. Just basic documentation house keeping.
Debug info for Jump Cheating could get stuck after a cheat detection event, keeping other detection events from showing properly.
Simple tweaks to keep Debug Output on screen longer as they would sometimes only show for an instant and be cleared away before you could read it.
Basic rework of Debug Info to not depend on multiple signal updates, but just one update now via the FPS setting chosen by the Client instead of every server frame.
You can now see how fast the server is scanning all the players in the Debug Info. This is useful if Roblox service issues or something eating all your Server CPU is causing slowdowns during the scans. 5 scans per second is the normal speed, but lower speeds will change the status color from Green , to Yellow (some slowdown, but still functional), to Red . Red meaning that some scanning is probably suspended on players until the Server Speed returns to normal or at least fast enough.
Developers with games that use custom player models (beyond the Roblox R6 or R15 meshparts) can now specify those MeshParts with an attribute that will direct the anti-cheat service to use those as new, additional scanning points, just like the hands or feet. Setting a boolean attribute “KM_MESHPART_SCAN_POINT” to true in Studio or live via Server Script will accomplish this. The more scanning points a player model has, the better the anti-cheat can avoid false positives on detection for Teleport, Fly or Jump cheating scans.
A logic glitch would reset your Max Speed or Max Jump settings if the Speed/Jump scanning was disabled on a player, then re-enabled later. Before, it would set those values back to what ever your defaults where in the configuration file. This could be an issue if your player had dynamic values that changed before (like for power ups, cut-scenes, etc.) The new behavior will leave any previous default setting as-is on the player object if they already exist when initializing the scan data on the player when enabled again instead of treating the player like they just entered new into your game.
I will update the developers guide information to include the new information in the near future as well.
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.
1/16/2025
New feature, Revocable Player Trust; allows the Developer to build trust with good players by incrementing a “trust” score based on either the time spent in the game with no cheats detected or manually set by the Developer as they see fit. Trust points allow exceptions to detection events that may be caused by latency or Roblox service issues.
Explanation of recent changes:
Wow, all this for one update you might ask? There is a good reason not to sit on it though, so hopefully this explanation will be helpful.
This new feature allows a developer to use a type of “trust” system for players. Basically players can build up a “bank” of trust points that can be later “spent” for detection exceptions. This system operates separately from any other type of exceptions or immunity that the developer uses and functions as a last priority compared to those two.
Since this is a new feature, it needs the newest version of the configuration file “KnightmareConfiguration” to be enabled for use. This is so it remains backwards compatible with older versions still being used by developers. You can usually just copy over your settings from your old config to the new config to get up and running quickly.
You will find the configuration section for this new feature near the bottom of the config file, right above the “Global Settings” section for reference.
Each type of the anti-cheat scanning services has [3] tuning settings so that each can be individually customized as the developer sees fit.
1st configuration option is the time delay, which functions like a countdown clock until the player is awarded 1 trust point. As long as no cheat detection is set off within that window, the player will get the point. If a cheat detection happens in this span of time, they will not be awarded a point when the count-down finishes. Once the count-down finishes, point or not, everything is reset to wait for another slice of time for the player to behave.
2nd configuration option is the type of “trust” to give the player. By default, if the player runs their trust score down to 0, it can eventually build back up again as the developer sees fit. If you enable this one-time trust setting, it means that if the player burns through all their trust, they will never be awarded more in the future via the time delay. It’s an “abuse it and lose it” type of setting for developers to use.
3rd configuration option is for the max trust score allowed. This basically caps the player at whatever trust score maximum you see fit to allow in your game. If you have your trust max set for 3, then no matter how much time the player behaves, it will never exceed it. This is useful at preventing players from just going “afk” in your game to try and bank a really high number to be abused later.
Finally, the developers have full control over the trust points and can change them as they see fit, such as awarding no trust to player accounts created today; to giving veteran players a “trust” boost if they have older account ages, bought in-game passes and such to progress through your game fairly, etc.
I will be updating the documentation for this as well, with much more detailed explanations and examples of how the developer can customize this new feature as they see fit.
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.
1/19/2025
New feature, Invisible Teleport Fence; is a developer set X,Y,Z (or mix) axis coordinate(s) that confines the player between it. If the player moves beyond your set limit, 1 of 3 actions may take place. If no safe coordinate is set for the player object, it will check if a global safe coordinate exist. If no global safe coordinate exist, it will use the last scan location as a fallback. A cheat detection event is triggered and the player is teleported back to the either the developer chosen safe coordinate or the last scan that did not violate the set limits.
Explanation of recent changes:
Another one feature update you ask? Yeah, because this new feature is very useful and has gone through enough testing to prove itself. While it was mainly created to aid developers with racing vehicle style games, it can actually be quite useful for many other genres of games as well.
This new feature allows the Developer to build a dynamic “invisible” fence around the players. By adjusting the axis coordinates that you want to limit, you can prevent players from teleporting way outside the bounds of your game world. If can be as simple as using the Y axis to limit the height of your game world, even in open space. To using all 3 axis (x,y, and z) to build a virtual invisible box around your player that they can not escape from.
Since this is a new feature, it needs the newest version of the configuration file “KnightmareConfiguration” to be enabled for use. This is so it remains backwards compatible with older versions still being used by developers. You can usually just hand copy over your settings from your old config to the new config to get up and running quickly.
You will find the new configuration settings in the teleport anti-cheat configuration section.
I will be updating the developers guide documentation for this as well, with much more detailed explanations and examples of how the developer can customize this new feature as they see fit.
Instructions for setting up your game to auto-update with each version release is located at the first post on top.
, to Yellow 
(some slowdown, but still functional), to Red 
. Red meaning that some scanning is probably suspended on players until the Server Speed returns to normal or at least fast enough.
Yeah, because this new feature is very useful and has gone through enough testing to prove itself. While it was mainly created to aid developers with racing vehicle style games, it can actually be quite useful for many other genres of games as well.