This could be useful. To tell between could give more insight in certain situations to developers like the why, where etc. I am sure you understand my point.
This is in the v2.01 now. As a new configuration option, you’ll need to use the newest configuration file to find the new option in the RPT section. The custom punishment module template has also been updated to show where the new argument goes (basically at the end of the function like all new stuff does).
--[[
When a player uses a RPT exception, this will also activate the custom punishment module.
The activation will also pass a new argument "rptActivated" to the function so the developer
can check if it was activated by the RPT system or not. This can be used to log how often a player
is activating RPT exceptions in your game among various other uses.
Default = false
--]]
rptCustomPunishmentEnabled = false
It needs its own option so you can run both this and custom punishments at the same time and be about to tell which is which. So, if a player uses a RPT exception, it will be passed to your custom punishment with “rptActivated” set as true. But if the player is out of exceptions and activates the cheat system again, then the “rptActivated” will be false instead, letting you know this was a regular cheat detection and not RPT related. This also makes it backwards compatible with older versions for those that don’t use the feature or even know it exist yet.
Vey nice. Also like how you’re taking feedback unlike others (visionary). Very handy
I try not to turn down good ideas that can benefit everyone. It’s different if someone ask for a “game specific” only feature, but the ones where everyone can benefit, I think are good.
Today, the knightmare anti-cheat service has finally moved to a “free” plugin version. This will allow anyone to get up and running with the (4) basic types of cheat detection quickly and if they decide they want to help out financially by purchasing other “plugin” versions that contain more “quality of life” plugin upgrades, it is completely optional. All of the information for this new direction has been updated at the very top of this topic to avoid making too much spam clutter.
Service update today.
I used to copy & paste the same message about manually updating, but now that everything is plugin based, it’s as simple as clicking the “Update Version” button and letting it do all the hard work of making backups, downloading the latest version and migrating all the settings.
This update is recent feature request from other game developers.
5/3/2025
- Jump Cheat detection will Sap velocity on all player baseparts instead of just the HumanoidRootPart. This will help with games not using R6 or R15 player models.
- RPT System now has new configuration options to filter players from the RPT system based on account creation age. These settings can also be tuned down to specific ping tiers as the developer wants.
Explanation of recent changes:
- Normally, Jump Cheat detection punishment is just sapping the velocity of the player, but it only focused on the HumanoidRootPart. A player model can have many more pieces with velocity that still might affect the player movement, especially if the game does not even use the Roblox R6 or R15 model configuration. The new change will sap the velocity of all BasePart class objects on the player model. This does a much better job than the old way.
- The Revocable Player Trust service now has some more ways to tune your settings via the Player Account Creation Age. You start with a Global Account age setting that allows you to set a minimum and maximum account age (in days) that the RPT system will process players. Then, if you are also using ping tiers, you can even set further settings of minimum and maximum account age for that specific tier. These settings allow you to filter players based on how new or old the account is that they are playing from. If you don’t want to giver players with brand new (usually alt) accounts any RPT exceptions, this makes it easy to keep your anti-cheat settings more strict for those players by not offering them any trust points, as an example. You can configure the new settings anyway that you want, even go in reverse if you want to be more strict on players with older accounts, etc.
Was wondering if you would be happy to add compatibility with the following module: https://create.roblox.com/store/asset/118463715896426/Report-System-Replay-System
Seeing how this is paid, it would not hurt no? This could be more of an admin menu thing however with Exe 6’s custom commands I could probably end up writing a command which will allow for interaction between all three apis.
It would be nice if you think about it.
I’m not familiar with the module, what does it do? I couldn’t get much from the description. The description says “Play the last 30 seconds!”, so is it recording player movement?
Sorry I forgot to send the devforum post of the developer. They don’t have an actual post for it I don’t THINK. You’ll need to go looking to what I am aware off.
DF: RoWatch - The First Free Mod Spectating Ui!
Hope this helps. Best I can really do here for the moment.
Hey, developer here!
First of all, such a pleasure to get my project linked right here.
The module is really simple, i think it’s like module:save, and it gives you a table with all the data.
Hope this helps!
So the save function does all the heavy lifting? Very nice!
@knightmb1 might want to look at this.
from what I know it does.
I ain’t home right now, but if I’m correct, and I’m thinking about the right version, it does.
It is the one you linked to the marketplace so likely you’re correct.
Very interesting. I was working on a looping player recorder myself some months back, but it’s been on the back burner for a long time while I was working on other projects. But it seems you already did all the hard work, thanks for the link. I’ll respond with any questions to the proper topic.