Bukkit

@MarkElf2204

Let's separate things here, build 813 is very old and has a totally different y-axis handling for moving checks than build 883.

• So you have the afk pool with fence post issue too?

Concerning passable (can't tell what you have changed):

• I suggest not to remove cancel actions from passable, because that's a pretty hard check with false positives only on some edges. If you don't cancel passable for low violation levels, the set-back location may be put into the block, because the player was moving inside there - shortly after that passable or survivalfly might cancel something and put the player back into the block.
• Can't really tell much without knowing details and if this happens with the latest builds, some things have changed significantly with the latest builds.
• If you want to get rid of passable alerts, just remove the log actions.

@Bobcat00

What kind of setup is that specifically? Like water with a fence pole instead of a slab ?

@File14

Not 100% sure what you mean, but i assume it's the temporary login denial thing, likely related to the chat check actions. In that case you can use "/ncp allowlogin PLAYERNAME" OR to allow all "/ncp allowlogin *". You can also remove the command actions from the configuration, or alter them to something else. The actions in the actions lists are "cmd:kickchat1", "cmd:kickchat5", "cmd:tempkick1" and "cmd:tempkick5", not all might be used. The commands are specified in the strings section under the keys kickchat1, kickchat5, tempkick1 and tempkick5.

If , for some reason one of the checks is denying login actively, /ncp info PLAYERNAME might reveal if it is the CHAT_RELOG check or the CHAT_LOGINS check.

@marubal21

Thank you for reporting the issue!

@Bobcat00

A cheat client is thinkable, like a cheap version of preventing to fall (unlikely, because 5 seconds are a lot) or it can be some sort of speeding/stepping or some other cheat that uses moving patterns to optimize something differnt.

Yet we do have false positives to iron out, and passable also may just alert for players trying to fall into the blocks during rendering after login/teleport. So perhaps the client has teleported/logged in there and doesn't render too fast, or it is a chat-only client with a simplistic implementation with always falling (...), for such one would need to examine different kinds of logs about that player. Another thing could be, if a player is testing getting through a button-driven door (legit or not), with the server being configured to use passable for doors as well (thinking of that... testing piston-doors with button-activation and latency is also "thinkbable").

Getting a lot of text for stuff that might or might not be the case - some of those things we will possibly be able to detect and hint at.

• Edit: Could improve cascading violations due to latency or chunk rendering, but that'll stay somewhat itchy/complicated/incomplete until Mojang/Spigot either do something about some those protocol-wise or at least improve support for checking for those things.
• Not sure you allow text-based clients, but in theory we could try to detect some by examining chat and matching vs. behavior.
• Piston tracking is just being implemented (though retract events are pretty warped, showing different directions with vs. without blocks, and we do need some more refined strategy like player activity tracking to confine memory use etc.).

Maybe we should add some smart framework thing, so we can queue some interesting things and log a little more detail triggered by some detection, where NCP might detect something that could also be false positives for some cases. Activating on-the-fly debugging using such triggers could also be interesting, though that would be quite a heavy thing.

@Bobcat00

Likely a false positive. Probably there is no advantage to go through the floor there. Could also be the chunks not actually being loaded, with a long staircase - not sure that's possible with 500 ms ping, i'd assume it's not possible without recent teleportation or extreme speeds.

Did you check the exact location? Was it on a corner-type-of-staircase?

@marubal21

I was suspecting that :). We could not find anything with fences (Blocks changing dynamically will have the potential to pose trouble, e.g. with plugins altering things or pistons, but that is another topic).

@Bobcat00

Passable with 0.1 blocks downwards could be login/join (client rendering stuff).

Stuck inside blocks is a ticket. Considering to re-add a workaround, for which i am not entirely sure why it had been removed in the first place (allowing to be on ground inside walls means allowing spider basically, but the workaround was a slightly different case with the center of the player inside the block).

Other cases may or may not be false positives (have they been observed to be false positives or are the players 100% trusted?). Some speed cheats will just stay under the radar as much as possible, some other cheats might also lead to collateral alerts with other checks. If your server is big or the regarded time is long, there certainly will be random amounts of false positive entries in the logs. It's another question, if there are special (plugin-based) effects or items with attributes involved, because there are a range of cases with the transition between switching states will lead to false positives.

Plans are to allow skipping cascading violations, setting back silently and only notify on long repetition of violations (sf + passable), but that is not related to occasional false positives. Another thing is reworking the entire horizontal moving model, but that is a massive change and will need time to stabilize, similar to all builds after 853 representing the new y-axis handling, a fundamental change, for which we will still be finding edge cases for a while.

@Bobcat00

Can't judge without details.

Guessing on survivalfly:

• Could be cheating. Did you just update from build 853 or earlier?
• Could be false positives (edge cases, or systematic.... can't say without details).
• Could happen with latency after one set-back or shorter range teleport of any kind. This might be slightly better with ProtocolLib (3.6.4 for MC 1.7.10 or below and then NCP build 884 or later).
• Build 886 does contain a fix for ender portal frame.

Guessing on passable:

• Passable will always/often show violations after teleport/join. Especially slow/laggy clients might. Could also happen after a set-back of other nature, due to latency. (see ProtocolLib note above)
• Could still have false positives.
• Build 886 does contain a fix for ender portal frame.

@MyPictures

It's been a bug all the way, for some part survivalfly with recent changes triggers something, but also passable. Possible there have been fixes in passable leading to this, but it's fixed in 886 anyway.

@marubal21

The portal frames should be fixed now, so you could remove the yonground setting (it wouldn't necessarily hurt to keep it, it allows players to avoid cactus damage, but it might also help with some edge cases, the default value is below 0.02).

Could you elaborate on fences?

• What type of fences pose trouble (also fence gate types)?
• Do you have plugins installed that mess with blocks (add/change)?