Bukkit

@chsedv

Added in development build 679, just minimally tested by inspecting nms code and with a local server.

@andrewkm

I am still following the conversation - build 677 contains a change that would let NCP fail earlier if it was causing this at all. It's not more "safe" to use than build 676 though, because it would fail during processing moves, if it happened at all (should not if there are no bugs).

@chsedv

I might not be able to test 1.7.8 much for a while, though.

@MasterMithrandir

What version of NCP ?

@mcminicorp

No idea, could just be client side/delay/lag/something - the Munchhausen check is disabled, isn't it?

@ridddle

Thanks for the info!

@KirjoZzZ

Use the latest development build for 1.7.5, we might push a (beta) release today.

Edit: we will probably make it release next day(s), some checks on potential fixes/bugs pending, want to have those in.

@KirjoZzZ

It means than NCP can't hook into the server to get more precise block-shape information and other, so it will use some "minimal compatibility" hook, only using the Bukkit-API that the servers variations usually all implement, usually happens if you are running a Minecraft version for which NCP has not yet been updated, or if you are running a more "exotic" mod that supports Bukkit but is differing from CraftBukkit.

To probably fix it:

• Can you show the full output of the "ncp version" command?
• What CraftBukkit or other mod build are you running?

@pookshuman

You need experience to tell cheaters, because nowadays cheat clients are highly adaptive, so they even have dedicated switches for NCP - often labeled as "bypasses", those adapt to the limits that just still work with NCP, hardly generating any violations.

Well, check what they are doing, if in doubt - have them explain what just happened and gather some experience with that, if they reach high levels or keep triggering violations.

Typical reasons can be:

• Cheats
• False positives
• Bugs
• Incompatibilities with other plugins.

Gathering extreme n-values in short time usually is a sign for cheating, however the well forged cheat clients adapt so well, that the differences become rather subtle, that's why some experience is needed.

I explained possibilities for false positives with the blockbreaking. Another check that can trigger a lot is passable, but it is usually due to a specialty in Minecraft (not a false positive, but also not a cheat, still can't be let through).

@pookshuman

Admittedly we could use a more striking documentation for how to judge this kind of output. A recent (pull-) request has touched this once more - we will add some better reporting commands that allow to find players with top violations and also more useful reports and collections of data for certain contexts like fighting and blockbreaking.

Basically that output shows something odd. For lag we would expect blockbreak.frequency and blockbreak.fatsbreak to trigger most, but apparently those are hardly involved at all.

Instead you are having a lot on blockinterat.visible and blockbreak.noswing. The visible check is relevant especially for "dumb nukers" and freecam, because it checks if the block interacted with is accessible at all and not behind a wall and such.

One should not be too enthusiastic about the VL number, because some checks translate things like distances or time differences into VL, so you indeed need to use the stuff in brackets for judging things:

• n = number of violations, probably most interesting for most checks.
• a = average violation level
• m = maximum of all violations

Unfortunately current stats don't really show how long the player was playing, so best is always to check once and after some time again, if possible.

This case at first looks like it could be a blunt nuker attempt. Visible and noswing trigger all the time. One can't be 100% sure, also because we don't know the time distribution. A nuker that just iterates over a cuboid might start underground and trigger visible first, then it hits visible blocks but triggers noswing because it is poorly implemented :p - a possible interpretation.

However other possible explanations could be:

• systematic false positives - some block shape is not interpreted right (e.g. outdated ncp version) while the player is breaking a block behind and that block keeps popping back up, this could also explain that some noswing alerts are there (roughly every second !?), we have those on WorldGuard regions with fast-breaking blocks that can not be broken due to protection - visible + noswing rather indicates to the block shape.
• Same as above but due to a client-desync: the client assumes the block is broken, whle it is not broken on server side, however the client does not receive the cancelling - this is as with the block shape thing, it can happen with very fast breaking blocks, e.g. with efficiency 5. (Edit: This demands the player trying to break the block that keeps reappearing a couple of hundred times, because this usually only happens with few blocks - with a high efficiency tool you quickly reach hundreds, though.)

Sorry for having this idea after writing all the text :p - you should let the player(s) show what they were doing, which block(s) were broken while standing/moving where...

Also check if you are running the most recent version of NCP (dev build should be ok too) with 1.7.x CB/MC.