@ctharvey

Ah, i forgot to ask in short:

• Are you concerned about the overhead for the light level checks during runtime? or...
• Are you refering to the output size created by the plugin when using the ingame command?

@ctharvey @tons of players:

You have tons of players? I might want to make the data saving feature more efficient and safe then.
How many approximately would that be, if i may be so bold to ask ?

I have not done extensive performance tests, yet light level checks concern 8 blocks, only for each block break, which is not a huge overhead. For almost everything hash-maps are used internally, so at least for the administrative routines the overhead for each block break is like "constant time" and shouldnt matter too much for something like 30-50 players that are online at once.
Concerning the data saving, given that the file is (by now!) written at once for the full data, the overhead is determined roughly by the number of players that have broken/mined monitored blocks since dt was active multiplied by the number of different blocks that are monitored. For 500 known players (on a 10 slot server not necessarily seldom, though later one could add forgetting unsuspicious players after some time of inactivity), given 20 monitored blocks, we have a data size of roughly 20*500*X for some X like 10-15, which ends up at a couple of kilobytes which are written to disk at once every 5 minutes by default (or whatever period you chose in the configuration). That would be (not exactly but pessimistically) twice the amount with light levels, like 30 kb instead of 15, which should not mean a too big difference in terms of the time penalty. Later i will see to it that only small parts are written back to small files rather, so that we will be talking of a low kb range probably only hundreds of bytes rather (Disk block size might be like 4 kb or bigger anyway.).

Maybe i am writing too much here :)
The slight problem i see with disabling light levels, is that that will pose the difficulty that swiching back to light levels logging will make either force you to throw away all old data or force me to add a second counter for the block breaking for the case, if the light level logging is activated again (because the light level sum has to be divided by the number of blocks involved, which should not include the blocks mined while the light level count was deactivated.).
So it would be more hard to make testing/switching "smooth", still that need not be a real problem.

@disabling features:

It is not yet possible to disable individual features (only global disabling for all is possible).
I might add that soon, though

@shortcuts:

Possible to add with next update...

I could allow for abbreviation of "suspicious" like '/dt su'.

Or would you prefer something like "/dts"?

And further: if you check "suspicious" - would you want the latest data to be worked into it as well (i.e. like adding the command '/dt digest' before calling suspicious)?
That could be '/dtsd' or so.

@MsohMage

Ha! The project is marked as experimental, so it seems people can not download the alpha file.

A simple solution is to name it beta. I will have to resubmit this for approval, though. That could take a couple of days.

There are alternative plugins like xray detection or so, which also log the rates. Not sure this plugin is better configurable, it might be.

I will add another option like some freq-threshold to only mark stuff as suspicios if a certain number of blocks has been mined (otherwise one has to check stats for the player even if only few blocks have been mined).