Bukkit

@ceagle2

It clearly looks like the server is firing the event and updating the PlayerConection to the relative amount of the position change and fires the teleport event with that as the target location as well, while the player itself is reset to the correctly calculated position.

Should be worth a ticket with spigot. I'll ask on spigot-dev IRC later.

Edit:
Was it command blocks for the relative teleport?

@ceagle2

Wonderful - allviolations + trace really shows the details in this case :) .

This (almost - because there could be other plugins interfering) certainly is a server side bug. It seems the server is setting the "last location" of the player to the relative amount of the teleport and is also passing that to the teleport event, resulting in "from" in the moving event showing the 0,0, 3.85 as well as the teleport event just before showing that coordinates. The server side must pass the correctly calculated coordinates there.

Are you running the latest Spigot version available?

@chrishillz

We are constantly "scanning", so scanning back or forth won't change the fact that all packets are scanned. In fact lag doesn't necessarily affect the survivalfly check (until the point when the morepackets check kicks in when it gets too extreme), the real problem is latency. With latency players just receive teleport events "much" later than they happen on server side, but the player is still moving and is sending their moves, even when a teleport has already happened on server side. Now the "move" the player sends only consists of the new location for the player and the server can not distinguish if it is a move from before one of the latest teleports or after such, so as a result we receive moving events with too big distances. This is a flaw in the Minecraft protocol, despite not being entirely simple to tackle, they would have introduce some kind of "context" for moving, changing with teleports and telling the client that the context changed (to 1234), thus the server can ignore moves sent for an outdated context. Given that the client only sends the target coordinate, we are not able to distinguish if the client "intended" to move from a former teleport start point or not, on server side it just looks like "they try to go THERE". The Bukkit API provides a moving event with start and end point, but the start point is just implicitly maintained on server side and rather equals the last teleport end point or the last valid move end point. Not much we can do, even crude heuristics like "silently cancel too big moves near an outdated teleport start point" won't help much, because the players might just be sprinting straight, such that they won't be "near" anymore within a split second.

@KevinEssence

What server version are you using? Currently build 826 is the latest thing for 1.8.x - we do have issues there, but i will try to kill off most survivalfly related stuff at least workaround-based this weekend.

@ceagle2

The documentation is still missing :) - it's been an in-memory TODO entry, guess i forgot. The cbdedicated flag controls if NCP is using the obc/nms server implementation access for testing things like block shapes and attributes. The dedicated modules are usually the fastest - the only reason to disable them would be for testing, in case of compatibility issues with incompatible nms/obc access provided by another server mod, or in case you want to use cbreflect all the time to support the development. Now cbreflect is a new compatibility module for accessing the attributes and block shapes for obc/nms, only using reflection, potentially being able to run on at least minor future updates of Spigot/CraftBukkit. It uses some consistency checking to ensure it's not using the wrong methods, and if it can't find/access something it'll either not be enable at all, or it'll fall back to the Bukkit-API-only version of the functionality. So cbreflect is meant to give us a little more future compatibility, also potentially replacing (currently) up to 20 other dedicated compatibility modules.

The command is "ncp debug player PLAYER_NAME" so maybe you left out the player part once? The output will be written to the current log file. Using a folder for log files allows you to use "ncp reload" for both ending all current temporary debugging as well as switching to a new log file, to keep things separated.

@MCTylerPVP

I absolutely agree that NCP should prevent that from the start, can you give more details? Have you ensured you were not having OP nor bypass permissions? A simple way to check is to spam in chat (if enabled) and get warned or kicked once. have you been in creative mode?

We should actually add a command to test all the bypasses for checks for a player.

@chrishillz

Survivalfly can create higher false positives. We kick to prevent extreme abuse killing the server, but banning seems to be dangerous, because the violation level can also become high with being stuck in a strange shape/wall thing, pistons traps, but also rarely simply with teleporting and latency, because the player keeps sending "hey i am now 6 blocks below", because the player has not received the teleport event yet but keeps moving, while the teleport has already happened on server side, e.g. with a lift.

To distinguish such cases with just a one-dimensional violation level probably isn't possible.

@chrishillz

We don't recommend to ban in general, because there can be false positives (...).

Since NCP does not (yet :p) support meta check definitions, like reaching levels for several checks, it's hard to find many useful and reliable criteria. We will try to improve flying checks etc. but there are too many oddities with moving, so it's probably not going to work to ban only on base of a one-dimensional violation level. On the other hand the extreme levels usually don't get reached by false positives, yet again the smarter cheat clients adapt such that they produce minimal or even no violations at all.

Concerning seldomly triggering checks, there may be very good candidates for banning, e.g. for flying with bedleave. But those aren't really used by any up to date clients, so it's just not really useful. Currently it's a matter of experience and observing, but maybe my knowledge is outdated, because i just don't try to find useful ban settings myself - probably others can comment on their config for banning?