Bukkit

@bananoke

1. You would add a cmd:... action to the actions list, like appending " vl>5000 cancel cmd:ban_fight_angle", then you introduce to NCP what ban_fight_angle means, by adding an entry to the strings section of the configuration, e.g. "ban_fight_angle: ban [uuid]" or "ban_fight: ban [player]" for using the name. Might also add a log action, but usually banning should get logged on the console.

Note that the accumulated sum of levels in "ncp info" is not the violation level a player reaches during playing.

2. Violation levels differ a lot amongst checks. In my opinion the only valid way to add banning is to test cheat clients and see what levels you reach (not recommending running cheat clients at all - might need to reinstall the machine afterwards :p). Some checks can have rare pretty big false positives, e.g. survivalfly for the case of extreme latency, though some NCP has to prevent, because the result from strange Minecraft/CraftBukkit behavior, resulting in extreme moves on rare occasions. In fact many cheats produce occasional small violation levels rather, so with banning the big ones one might catch the false positives - in general moving of players is a very unreliable thing, i would not ban there. Candidates could be fight.angle, but i can't tell a level for which it pays to ban.

3. His info getting removed? You mean the violation history? I don't think that would be much relevant, concerning memory consumption or so, because data would be kept until shutdown only.

Banning has the problem that cheat clients adapt to us, in order to create as few as possible violations, thus you would tend to ban players who suffer a bug or a regular false positive or some other networking oddity.

@SaDb0y

Most of the time cheat clients adapt to the limits plugins like NoCheatPlus set, thus people can still activate the cheats, but the gain from it is limited.

Now the questions is what can they really do...

• Anti knockback: Known issue, we can't force players to move, but we might be able to detect such. No quick fix to be expected.
• Kill Aura: They are clearly limited in what they can do, but we can't prevent them from auto fighting, probably neither from fighting better than the average player. I hope we limit it enough, such that normal players stand a chance in active fighting. This is an always present topic, so there will be advances from our side, but we can't promise a new world here. Officially fight checks are in focus, just a little delayed due to the current changes coming with 1.8, which need a lot of attention on side of other plugins and servers.
• Speed hacks: Also an all-time problem, because Minecraft does not really allow for precise checking, similar to fight checks this will be in focus as one of the next things. They should be limited to some amount (30% max on ground?) of speeding, but we will try to limit it further.

@bananoke

With lagging players hopping about in circles around each other, some things could accumulate, als regarding that the info command does not show how long the player needed to collect all the violations - a minute of a cheater can match a day of a fighter.

If the player reaches that quickly, it could well be cheating. Don't be blinded by the vl sum (16000 for angle), the whole system needs a rework to allow for auto-judgment better - look at the values in brackets:

• n number of violations
• a average violation level reached
• m maximal violation level reached

Edit: the violation levels relate to the added amounts of violation level, not to the total level, that could also be misleading, because the actions for a check relate to the level noted in log actions with [violations].

So a high n probably is a better indicator than the VL sum. Best compare to trusted players. An indicator for cheats can be the amount of fight checks that triggered with somewhat significant numbers n (provided it's not a full day in an arena or so) and also because the improbable check kicked in. Still even with these stats you can't be 100% sure, because you need to relate them at least to the time that the player needed to reach those. Likely cheating, slight chance of rare fast-clicking + lagging player fighting a lot, would not ban, unless you get more specific input.

@MyPictures

Can you reproduce it either way?

@mcmonkey4eva

Usually problems with interact.visible are related to running a server version for which NCP does not have access to the block shapes that the server would use.

I am not 100% sure what's up with snow, because the height level is calculated by NCP anyway, though the interact.visible check might be slightly different than the on-ground checking.

We ask for the output of the "ncp version" command usually, or at least the add the server version to reporting something, in order to be able to relate it to known issues on either side.

So does "ncp version" tell that the bukkit-api-only module is in use? If so, we'd recommend to update - note that the current dev-build branch will be pushed as release this weekend, unless there is any sever issues reported within "no time".

@Darknessorising

@FabioZumbi12

Alright :).

@StaNNiE0

Plugins reloading plugins has proven problematic in the past - reload seems to be ok-ish with NCP now, but we always had problems with plugin manager plugins. Not sure if we can do anyting to improve compatibility on that, but basically "ncp reload" or restarting should be the way to go. Could also be that plugins that hook into NCP have been written to only consider the case of all plugins getting disabled/enabled as it is with reload and restart.

@LordKainzo

We are setting worlds to null for temporarily used Location instances. If such an object gets passed to any external API there would be trouble, because before other plugins could process it, the world would be set to null due to the cleanu (necessary to prevent memory leaks due to world references).

I found a spot with passable violations (very common), which might pass a Location instance for which the world gets set to null. Not sure if this explains why there is the exception in the player-join handling of NCP, though. This is corrected in build 697.

@StaNNiE0

There seems to be some other problem then (permissions plugin or a startup error?). Did you check the startup log for errors? What's latest (build number?)? Which version of CraftBukkit/whatever are you using?

The regen is not caught by NCP ?

@jet315

Adding to @Darknessorising: The notifications give you an idea of what is happening, for big servers you will likely turn them off, rather. NCP is configured to prevent stuff by default, so usually the alerts mean that something has been prevented for the x-th time. Alerts usually don't appear with every violation, but after a certain amount/level of violations. Since server owners have a much different view on things, there is no "way to do it right" in general, though i would also prefer to rework the alerting/levels system, if i should find the resources to do it.

We only use kicking where we are somewhat sure that false postiives are rare and also where we think that kicking is needed for performance reasons, or because an action means trouble for the server, e.g. crashing or extreme spamming. We don't bring in too much kicking also because NCP usually prevents enough to not need to kick. We don't encourage banning for similar reasons, specifically for checks that have false positives more often, e.g. if influenced by client-side or networking lag.

Things differ a lot by type of server/players and size of servers, but kicking and banning is problematic, because Minecraft+Bukkit does not give too much means of verifying most things in an efficient way.

@TheOnlyRealTGS

Our bakery license has expired!

@Darknessorising

Alright: /? might work. Your problem is now that it shows the default Bukkit "no permission" message? If you add '/?' to the nopermission commands list, that is the default behavior - what do you want to reach or what do you expect to happen instead?