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. 
1 Like
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. 
1 Like