Slowness+bunny will still not fully work, because we need to model
closer to the client here, i.e. acceleration and friction. Remaining
issues in rough order of naughtiness:
* On-ground friction based speed decrease.
* Increasing of speed, above slowness sprinting speed but below normal
sprinting speed.
* Two-step bunnyhop, having h-speed increase to bunny with two packets.
Similarly acceleration effects when touching ground, not modeled right
by bunny.
* Possibly more.
* Remove early return, as we prefer to know what NCP would allow, at
least until sf changes have stabilized.
* Only count in speed effects for normal running/jumping, not
water/web/blocking/sneaking. Either check potion effects or attributes.
Mainly catches the instant ladder and too large moves, generalize step
to have general "reset" as condition instead of "ground", don't limit by
a distance.
* Not actually a fix for anything we encountered.
* Nailed down blockinteract.visible raytracing issues to bad end-points
for raytracing.
* Also test/prepare logging test-cases for raytracing in general. Not
enabled, because we should have some flag/permission/command to check
before logging ~ 5KB per interact event.
This makes logging all violations potentially useful to use alongside
with the "ncp debug player" command in production environments. The flag
debugonly must be set with at least one backend being activated.
Similar to TestNCP but reduced/different features:
* Config: trace for the log file and notify to send to notify channel.
* It's not possible to confine whose messages you receive (yet).
Meant for better local/quick testing in the first place.
* Make attribute methods consistent (remove the sprint boost modifier
from the generic speed multiplier, because it's inconsistent).
* Add missing implementations.
* Adjust default sprinting speed modifier.
* Add more guards for the latest compat module (1.8_R3).
* Add a reflection based compat module for CB, to cover minor updates.
* Possibly other minor fixes/changes.
[Hail "insufficient data written"!]
When the respawn/login location is obstructed, the respawn event shows
that location, but the first move will start at several blocks above,
without having a teleport event to rely on, thus this workaround.
Vertical velocity handling can be much simplified (and possibly extended
to including downwards velocity) with using a friction-based modeling.
Absolute envelopes can still be checked extra, where appropriate.
Not very efficient in terms of code-output, but enabling us to log test
cases for visible (and potentially passable too), using real-life
examples.
* Add the capability to log a FakeBlockCache as java code.
* Add utility to record map parts (cuboid, ray-tracing with margin) to a
FakeBlockCache.
Missing:
* Actually log stuff (visible).
