Bukkit

@Bobcat00

That is the current default actions :p (those have an extra vl>30: .... :icf).

@YoungPvProck

You should keep it at default, NCP will decide by Minecraft version then. Is there are reason to "disable" it? What do you want to reach?

@Bobcat00

If it doesn't matter that cheaters can move through solid blocks, you could of course turn off the check (even selectively for a world). Otherwise i'd say leave the check on and remove the log actions for passable.

The passable-violations at login and for (some) teleports are not false positives in terms of what the check is checking for (moving through solid blocks), of course those players are not cheating. At present an actual cheater would probably cause much fewer violations with passable, so in fact one would have to look for that, which in my opinion renders the passable logging as it's done right now mostly useless :).

The slowly descending moves are sent by the client during receiving + rendering the chunks after join/far-teleporting, they are a workaround added by Mojang because without that their vanilla flying check would kick players for flying if they log in in-air.

In theory extremely slow/delayed clients might receive the passable teleports with a (strange) delay after their chunks rendered, so they already started moving - in effect they might get teleported back after starting to move. That situation might also cause morepacketsviolations and probably survivalfly too, not sure it still can happen, it seemed to be very rare.

So once more, as the passable violations mostly appear while the player is not even seeing the map, i suggest keeping the check active but remove the log action(s) from the passable actions entry in the cofniguration.

@ItsLemonmelon

Answered in the ticket thread...

@Bobcat00

As far as i can judge false positives should be rather less - what situations are problematic?

Passable will always generate messages after people join/teleport, but those are necessary for protection (not the messages but the cancelling of actions), so ensure to have another reason to turn the check off (and not the notifications).

@Difd9

60-80 players already is a lot, "most" servers have much less players, of course you get "constant" input. False positives exist, partly for reasons, but at least they exist - in some checks you might configure to your needs, but for protectiong against some things one has to live with a few false positives in general (not meant final, but Minecraft+multiplayer isn't a combination that allows efficient anti cheating with some precision and without false positives).

The leniency thing probably can't be added so easily, because we have a lot of configurability already and global/generic levels might just break custom configurations. Maybe there will be auto-config commands some day or we just fix things.

Ping - we do account for server-side lag and on some checks for client-side lag too, we can't allow arbitrary amounts of congestion/lag, some checks are configurable concerning that.

What version of Minecraft are you using and what version of NCP (just paste the output of the "ncp version" command)? Sometimes people just use outdated versions of NCP, ensure to use the lates (beta) release from BukkitDev at present.

@MCTylerPVP

NCP roughly does:

• Detect cheating - however given how Minecraft is made and how plugins/software is made, there can be false positives, depending on the check more or less rarely, of course we try to reduce those as much as possible.
• Prevent the effects of cheating. Sometimes this is directly possible, most of the time we can only limit what cheaters can do.
• Log cheating depending on context. This can be in-game alerts, console, an extra log file.
• Be highly configurable (what exactly to do when a cheat is detected, how/what to log, alter the sensitivity of checks, compatibility options for more or less specific contexts).

Preventing cheating is probably the most important for most people who use this plugin :). The default alerts could be "better", however many people usually want many different "betters", so we put it roughly were most users might be. The alert system has not been made for showing to ordinary players, it's rather aimed at informed server staff (admins, mods, also server owners), due to false positives some configurations might need a little instruction or experience to actually judge.

Informing players is a noble thing, but it'll end up not being too accurate, because nowadays hack clients tend to stay under the radar by adapting to anti cheating plugins, so unless for the "too simply coded hack clients", you'll be asking yourself "is this a false positive?". For some cheats one of the biggest jobs NCP is doing, is to set limits for cheat client developers, so they have to adapt to not get detected, hopefully allowing legit players to stand a chance in game play.

@Robson112011

In theory you can use the latest version - we have kept the basic compatibility modules for 1.5.x, however it's been quite a while since we have tested 1.5.x ourselves, so it might be we have killed off compatibility with a general Bukkit-API dependency update. In any case if you use the latest (beta) release from BukkitDev, please test it on a test server first if any errors appear, we will still attempt to keep compatibility up, provided we are supplied with bug reports and that you test our suggested fixes.

The current state of NCP should be "better" than the old versions, concerning cheating. Performance-wise it can't really be guessed in one go, because on the one hand there have been performance improvements like asynchronous logging or just optimizations, on the other hand the number of checks rather has increased and some of the damage API handling will be more inefficient on 1.5.x.

So i suggest you try the latest (beta, 3.12.0 or later) release and please report back if there are any errors and maybe in any case the output of the "ncp version" command, so we can see if everyting is put right.

@MCTylerPVP

How about turning the console messages off, if you don't want any? Do note this is Minecraft-multiplayer and not a 2-bit simulation of "good weather vs. bad weather" :p, false positives are pretty common. We will certainly always work towards reducing false positives, however we do rely on user-feedback to fine-tune settings, and we do encourage server owners to configure for their needs, there are too many different approaches to what people want to see and what not.

@MCTylerPVP

@MyPictures

The passable check triggering after teleports/join is a usual thing to happen. It might reach some level with slowly rendering clients.

The passable violations don't really tell much, because one attempt to move through a 5 blocks thick wall gets you one violation, but the vanilla Minecraft client might produce level 40 just with rendering chunks and sending "fake slow falling" moves while rendering chunks.

It's probably totally legitimate to remove the log actions from the passable check.