Because Spigot changed to fire the teleport following an altered move
end point with TeleportCause.PLUGIN, we have to alter set back handling,
so we can ensure to keep TeleportCause.UNKNOWN for setting back players.
Instead of altering the move end point, the event is just cancelled, and
a teleport is scheduled (with a dedicated TickTask method). Uncancelled
moving events mean removing scheduled teleports.
[BLEEDING]
* Comparably simple change - more places and special cases may still be
uncovered.
[BREAKING]
* Plugins that may rely on the exact sequence of things within NCP, as
it used to be.
Random
* Change "set-back" to "set back" everywhere for simplicity, and to
obfuscate the actual code changes.
* Set backs are now going through MovingListener.onCancelledMove instead
of MovingListener.onMoveMonitorNotCancelled.
* Illegal move handling would still use event.setTo.
* Split log messages: ingame vs. console+file
* Alter flylong to contain tags.
Performance-wise, it's not optimal that flylong is the same as flyfile
at this stage. Not sure if to remove flylong in favor of using flyfile,
to indicate it means details - main objective is to get minimal details
into the violation log, even if people edit it out of the ingame chat
messages.
Players and vehicles:
Instead always use UNKNOWN, as that is what results from
PlayerMoveEvent.setTo(newTo), as we use it for setting back players.
This should break functionality that relies on TeleportCause.PLUGIN
being used, possibly more likely with vehicles.
Internally, the tick is stored with a change id, so we can reuse a
changeId, if the tick is still the same, preserving rough order, as the
changeId should at least increase with the tick.
This isn't the last word on a public API, there likely will be the
following additions.
* One more simplified method with a minimal signature for simple
(non-push) entries (worldId, x, y, z, previousState).
* Optimized methods for adding multiple entries at once. Likely for
adding multiple entries of the same type/data/shape. Plus perhaps
simplified signatures to do without changeId and tick.
(Not sure if there will be need for a method allowing for a collection
of a to be defined class combining x+y+z+previousState.)
This will evolve based on feedback from GitHub issues.
Lots of issues remain with elytra, with and without boost. Selection:
* maxheight will trigger with the rocket feature, naturally. Mendable by
increasing it via configuration
(checks.moving.creativelfly.model.elytra.vertical.maxheight). Not sure
we'll just increase the limit or alter how it's dealt with (e.g. also
for sf: lock to a max / high slope value, independently of the set-back
and world height, alter as necessary).
* All sorts of transitions, e.g. onto ground, into water.
* Loss of boost right after adding (not sure if already fixed).
* What with hover, actually?
* Is the flight duration infinite with power 127?
* Issues with ascending after descending, even without boost?
Changes contain:
* MCAccess.dealFallDamageFiresAnEvent -> true
* Always log basic data on (handled) fall damage events.
* Add a tag for the cancel reason with NoFall. Alter the default alert
message.
* Move 3.0 to Magic.
* Set the skipping flag correctly on allowFlight being set.
Fall damage is adjusted or cancelled, if the Minecraft fall distance is
greater than the distance(s) tracked by NCP (per move diffs, maximum y).
Intention is to prevent (speeding by) self damage by abusing Minecraft
dealing fall for untracked moves.
Issue: https://github.com/NoCheatPlus/Issues/issues/338
* Auto generate the sub-module file structure.
* Add rest manually.
Rest
* Enter new classes into factories.
* Add entries for modules and dependencies to the root pon and the
NCPPlugin pom, to make the new module represent 1.10 R1.
* Point the 1.10_r1 build profiles to the new module.
* Add a new module for 1.11, point to cbdev (which still is 1.10.2,
though).
Next steps (next MC release, probably):
* At least auto generate a file, containing all entries to make for the
new module, for convenient use with copy and paste.
* (Later: alter the files automatically, possibly interactive. Needs
more care, e.g. if profile entries already exist. The factory entries
can have a marker each.)
