Reason for having this is:
- Spigot server now makes altering the end point of a move a "PLUGIN" type teleport, while it had been an "UNKNOWN" type teleport. In effect other plugins will activate teleport based features, assuming a feature based teleport, e.g. with resetting a /back location to where the player just was. Apart from enabling /back based cheats like "/back-glide" in theory, this is a highly undesirable situation, because it kills off either plugins features (disable fly check or disable feature plugins, due to not being able to distinguish).
So directions i am considering are:
- Fixing this with the current system somehow (needs reproducing with debug logs).
- Use ProtocolLib and nms-access to intercept and alter the implicit (non-Bukkit) teleport following cancelling the PlayerMoveEvent. Provided everything is accessible within nms (like last positions stored within entity and PlayerConnection), this would make the set back immediate like before, just better, because the PlayerMoveEvent is cancelled now. Plugins guessing where the player is teleported may be mislead (rather minor thing, NCP is important on that account) - more important, this would let us effectively hard-depend on ProtocolLib, unless i can fix the issue for the non-ProtocolLib users.
- Add a way to CraftBukkit, so NCP can cancel a PlayerMoveEvent, but still control the location the player is set back to immediately with cancelling the PlayerMoveEvent. (Needs ticket + pull request to succeed.)
- Add a way to CraftBukkit, so NCP can set the end point for a PlayerMoveEvent, and control the TeleportCause that's used for the immediately following teleport, e.g. setTo(Location to, TeleportCause changeReason), so the player is set back immediately after all plugins have received the altered PlayerMoveEvent. (Needs ticket + pull request to succeed.)
- Add a PlayerTeleportEvent with the new TeleportCause.CANCEL_MOVE (or something more abstract like CORRECT_POSITION) to CraftBukkit, to follow whenever a PlayerMoveEvent had been cancelled, in order to allow pluins to control the set back location. (Needs ticket + pull request to succeed.)
The last one is most tasty, because it combines telling plugins "not this move" with having an explicit teleportation event, at the cost of some performance for setting back players - which then again is gained by not having to process cancelled PlayerTeleportEvents as much. Of course we could distinguish old method vs. new method, depending on Minecraft version.