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.
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/26/2025
Requested configuration option to disable the background of the Debug GUI added.
Requested color codes for print statements to help visually spot successful starts added.
New feature, Revocable Player Trust Ping Monitoring; you can assign latency ranges to Forgiveness Tiers that will influence how the RPT system builds trust with players. This allows the developers to offer more or less trust based on the real-time latency of the players in-game.
Explanation of recent changes:
There is a new configuration in Global Settings to disable the backgrounds on the Debug GUI for developers that need to do this for visibility reasons during debug game play.
Basically, emoji colors added to the anti-cheat system print statements for startup and code updates so that developers can spot them easier in the output window against a lot of other debug output text.
Revocable Player Trust now has a new Ping Monitoring feature. The developer can setup 3 different ping tiers, each with its own customized Trust Bonus modifier that will influence how the RPT awards Trust points to Players. These new settings are located in the RPT configuration section.
You can setup the Tiers anyway you wish, customize the Trust Bonus of each type of cheat detection. These bonus amounts will be added to the Player Trust Score when it is awarded by the RPT system. Depending on how you setup your Forgiveness Tier, you could allow partial Trust Points to build up to full Trust Points over time, to help curb any potential abuse by exploiters.
You can also use negative numbers to slow down trust building points for players with better pings than their peers, such as using -0.5 so that the low ping players are only awarded 0.5 trust points instead of 1 trust point each time.
Since these are new features, 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.
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 these new feature as they see fit.
Knightmare Server-side Anti-Cheat Services now has a plugin front-end for Roblox Studio integration. For those that want to support this continuing evolution and updates through monetary means , this is the easiest way. The plugin GUI makes configuration and updates so much easier than pouring through config files or manually downloading models to update the services in your game. It will also expand and update over time, so your one-time purchase will go a long way towards the future.
This doesn’t mean the free download model will go away. In no way will that happen to all the great developers that have supported and helped me shape this anti-cheat service over the years. For those comfortable with going old school to manually configure and update the service for their games, that will continue on like normal. The only change is the shift in focus to pushing all future updates and features through the plugin and still maintaining all the great stuff that any developer is welcome to use for free like they have always done.
In the creator marketplace, search for knightmare, should be the first match. It should have an artwork logo and lots of screenshots showing what the GUI config looks like, etc. Basically, everything in the plugin is self contained. No need to place models in your workspace or go through a long config file to make settings changes. Everything is contained in one folder, service files, backups, etc. It can also download new versions as they are released and auto-magically migrate your old settings to the new version, create a backup of the old version just in case, lots of fail-safes to make sure developers never lose any settings. The plugin won’t be static either, as new services or features are added to the core services, the plugin will be updated automatically as well, basically buy once, use 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.
2/2/2025
Fixed logic issue with invisible fence where using 0,0 for axis turned it off by design, but also using 0 and any non-zero number would also turn it off, like 0, 25.
All Custom Punishments run through pcall (Protected Call) so that any downstream code errors will not crash future monitoring on that specific player.
Updated Speed Cheat Counter for Debug Window to show even when Player is NOT moving; this will aid in developer testing and tuning of the speed cheat detection.
All raycast and radius cast checking has been switched to only look for the CanCollide property of the part object instead of a combination of CanQuery & CanCollide. This was causing issues for developers that need to have this property disabled for their own internal game needs.
Explanation of recent changes:
When using the invisible fence feature of Teleport Cheat detection, you can disable specific axis scanning by just using the values of 0 in both the positive and negative limits. A logic bug made it also disable this if you just used 0 and 25 as the values for example. Basically, any 0 found made it think you wanted to disable scanning for that axis. This has been fixed.
All Developer Custom Punishments go through pcall, mainly to help protect against some downstream code error (like maybe a wait for an object that never appears and crashes code downstream) that would end up crashing scanning on that specific player. Other players would be unaffected against future scanning unless the issue affects all of them.
Requested update to have the Debug Window continue to output the Player Speed Cheat Counter even when not moving for convenience reasons.
This update was a small change, but has a big effect server wide. The Flying, Teleport, & Jump cheat detections all use ray-cast and radius-cast to find collide-able objects around the player. The original behavior would actually ignore objects if they they had the CanCollide property enabled but had the CanQuery property disabled. This visual “quirk” in Studio made it confusing for devs trying to figure out why scanning would “see through” objects meant to be collide-able for the players, cheat scanning, etc. Some developers might also have another purpose to disable the CanQuery property of an object but still want to keep it Collide-able. Since the anti-cheat service is about dealing with collide-able objects, there is no need to ignore a solid object based on the CanQuery property, cheat detection wise.