Bukkit

@MCTylerPVP

Of course we want hacks covered out of the box. Currently a couple of checks are buggy and have to be repaired, but you also have to account for the fact, that many cheats are just adapting to the plugins on the market, so they try to stay off the radar. In addition to that there are a couple of client-side-only hacks, which can not simply be fought on server side, like marking enemy players or types of radar. Other things we don't monitor due to the complexity and the fact that Spigot and other plugins cover that sufficiently well, e.g. xray or spamming fake entities out of sight.

Currently we are focusing on fixing false positives in survialfly. Then we will make fight checks operable again (specifically fight.speed), and improve/add other checks, e.g. flying, hitting through walls.

@File14

Can it be reproduced at will? Maybe we'll have it fixed soon anyway, but more information coul be useful (1. /ncp version 2. [tags] in flylong and flyshort messages).

@adambll

You can remove the log actions (log:.... until the next space) for the checks.moving.morepackets and the checks.moving.passable checks , at least for the lower violation levels then.

@Har88

The parts in ProtocolLib can't be done with the Bukkit API, so those features might be missing. It needn't be the world, but the spamming of moving packets (without causing Bukkit to fire an event for it), had been used to freeze other players locally an get rid of potion effects (and other), not sure it is that much of an issue with latest Spigot. The SoundDistance check attempts to prevent player locations to get revealed by lightning effects, matter of taste.

In future we will code more for packet level, e.g. a replacement for the fight.speed check, which had been rendered inoperable by a change in CraftBukkit a while ago.

@Errota

There already exist tickets on that one. I myself can't reproduce this, but i assume that we will either get it reproduced or make a workaround (set back to void).

@Theepwner

Good point!

@martini002

They might be able to abuse velocity dealt by damage, because NCP is too lenient in that case (known issue). This will be tackled very soon, though we might go for a (beta) release with current changes in first.

@ariefun123

Currently it depends on the server version. The fight.speed check has been rendered inoperable by not-that-recent-anymore changes concerning how events fire, so we will have to replace it by a ProtocolLib-based version for servers since roughly 1.7.10. Above that version we only can process the hits that would count as damage, which usually won't be many more than 2 per second max., thus the need for ProtocolLib, in order to get the unfiltered input from the clients.

Assuming it was operable at all, we have several limits built in.

The short-term monitoring is done by fight.speed and is split into "normal" and (very...) "shortterm" limits. Monitoring 2 seconds by default, the default limit is at 15 attack attempts per second, allowing a little burst/congestion with monitoring 2 seconds. To prevent sending all at once, there is the extra "shortterm" limit, limiting to 6 attacks per 7 ticks by default.

To monitor mid-term attacking frequency, the combined.improbable check gets fed data with each attack attempt, and that should usually result in a slightly lower limit than 15/second, but it is monitoring 30 seconds or so.

I'm probably not very concise here, but basically we have to add in a replacement for the fight.speed check, until we can actually monitor the attack attempt frequency. Once operable, there are three levels of limits as described above (shortterm, normal and mid-term).

@xXGrammar_NaziXx

Yes, that'll be interesting. It might also be related to the client-side or the specific routing via the internet in particular, so it needn't be a server side issue.

Usually we try to detect server-side lag and have NCP be more lenient then, but it can be with lower-grade HW that the meximum leninecy isn't enough.

Remains to be seen....

@xXGrammar_NaziXx

Probably we should take this into a ticket, if it stays an issue, keeping track of the details will be difficult over time.

• morepackets: This usually happens if the connection or the client are creating congestion somehow, e.g. with eating up all uplink with torrents or map uploads, or certain mobile connection with too few uplink, or just the internet doing something weird. This check can be configured to cover more time, which might cover up for the low-vl issue. Now the check already covers 6 seconds, but there could also be special cases leading to this. You can also allow more packets per second, but that will also allow more speeding.

• passable: This check is pretty "hard", in terms of creating violations when people move into blocks, that they are not supposed to move into. It still might have false positives. I could not create passable violations on 1.8.8 quick testing , but that doesn't say much.

Are any speed potions or other involved, do the messages happen often? Any other side conditions? Could consider recording a debug trace (or if crafty enough, set checks.debug to trace all players, only if HD is fast), if we can't nail it down.

@xXGrammar_NaziXx

In fact the features do tell some things :), just paste the whole thing next time. Not saying those are relevant here, though.

So players get set back by moving checks - how many players complain (and how many players are playing at all)? Can it be confined to certain actions/situations, like jumping off block edges, the first move, continuous sprinting+jumping, only during fighting, whatever?

The survivalfly check is much in focus right now, so we will keep changing/fixing.