Bukkit

@elitewiddi

We need the output of the "ncp version" command, to know what versions we are dealing with. We could also have a look at your config of NCP, to see if any old default values or changes are present (use a paste with YAML format, e.g. BukkitDev paste - can PM).

Otherwise there are some things you can check/do for starters:

• Direction check:
  • strict: false.
  • penalty: 200
• Reach check:
  • penalty: 200
  • MAYBE (only if it is still problematic, after applying the other changes):
    reduce: false

@mod_masta

Horizontal velocity is processed separated from vertical velocity, for finding cheats the most interesting part of velocity should be the horizontal part. Unfortunately NCP has to guess when the client is using velocity, so what could we detect:

• Players not moving at all, though should/could.
• Players moving slower than should.

@Starwars291

Thanks!

@mod_masta

Fighting checks will be in focus from now on, for a while. However there are some pointers about what you mentioned:

• The number of hack clients does not necessarily relate to their abilities :p.
• Auto armor probably does not pay too much. If i see this right it is a relatively seldom event, which can be done pretty fast with legal means as well (precise clicking). There might be something possible with preventing certain inventory interactions while moving or dealing attack penalties with certain inventory manipulations such as moving items. Estimating the severeness (i.e. gain from fixing) vs. the amount of work, i could imagine dealing attack penalties, but anything more complex will probably not happen soon. If you have any thoughts on details/usefulness...
• Auto aim and Kill Aura will always exist, the question is what gain´they represent over a vanilla player, having NoCheatPlus in place. Since fighting checks are in focus right now, situation might improve further.
• Anti knockback is complex-ish and will not quickly follow, mainly because the client/player decides about using velocity. We could add some detection "quickly", however with the current velocitiy-tracking it will also have a lot of false positives, so it could only be used for teleporting and watching, rather than auto-punishing or cancelling. For reducing false positives, the problem is that the client on player-side decides when to use velocity, so the velocity arrives with a delay at the client and the effect of the velocity on the player arrives with another delay back at the server. Players can be stuck/blocked by surrounding terrain at some "arbitrary" point of time after the velocity was sent from the server. So we have the problem that the player can have covered a good bit of a distance since the velocity was sent, and at some random point of time been blocked such that the velocity would not get consumed and the check might trigger. Of course we could keep checking for if the player was blocked towards any direction and keep track of such for the last so-and-so seconds. However this means a lot more checking (4-6 directions, 2-block-high, 1 or 2 times per move). Maybe the only way to do such consistently would be to fully integrate this kind of checking into the "on-ground" checking, which then complicates the code by a lot and makes it more difficult to maintain and also change partial concepts. Maybe we will come up with some strong simplifications, like accounting for "a lot of air around", but it's not something we can promise much on.

@elitewiddi

Some things might change soon with fight checks in focus right now.
Edit: Can you check with "ncp info PLAYERNAME" before and after such situations, for both/all involved players if possible? There might be some things that we can do by configuration already, also there can be new type of hacks involved that make it more difficult to get hit.

@Bobcat00

We will need details. It could be false positives, but it could also be "en vogue" hacks spreading, e.g. to avoid damage in fighting.

If it seems a problem best would be opening a ticket, we need at least:

• Complete output of the "ncp version" command.
• More information on server type (survival, parcours, ...).
• More information on number of players online, for a rough guess (occasional false positives will be much different comparing 20 vs. 200 slots).
• As much as possible information about how/when/what violations are "seen".

@Bobcat00

It's new in Minecraft and CraftBukkit!

The release for 3.10.8 has an option to increase compatibility with the buggy ctrl-sprint feature, however it is not activated by default in 3.10.8 - next release will have it activated by default.

That would be setting checks.moving.assumesprint to true.

@EvilWosby

"kicked for fall damage" ? Did you add a kick to the nofall-actions ? Or did the player trigger a nofall violation and then get kicked for .. what?

Also do players take fall damage with dismounting from a horse into water in vanilla?

I would be interested in the full output of "ncp version" and maybe a plugin list (maybe pm, if possible).

@FlawlessSin

Can you be more specific? Do you have a certain situation in mind, like dismounting?

@Robson112011

Thanks, that's what i would expect on consistent problems.

I have to check what we changed since, concerning the vertical move/accounting, there have been fixes but not too much of a change, if i remember right. Is it always/often "vacc" ?

I will try to find the time to test it with 1.5.2. Meanwhile you could try one of the following:

• Disable vertical accounting (at the cost of making glide hacks more "easy").
• Disable dealing damage on survivalfly violations (Does not prevent the set-back, but death - at the cost of not punishing certain cheating attempts with long fall distances.)

Can't think of more right now, will update if i find anything suitable.