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).
This is not the thing (lots of yet), but it is a small step.
Refactor:
* Use access methods for several details on vertical velocity.
Fixes:
* Dont reset the current jump phase if there is vertical freedom left,
because the next jump might then cause a violation.
* Fix clearActiveVerVel (remainder used to clear hVel, yet unused).
* Clear vertical velocity on removeAllVelocity (!).
* Keep setting sfDirty if velocity is found, to prevent premature reset.
Missing:
* Some resetting conditions for sfDirty might be missing.
* Implement an error counter increasing with velocity-add by 1.0 or
slightly more , decreasing with violations, but undo violations if count
is > 0.0. Use at least for vertical accounting, in order to go stricter
on cheating with velocity.
* Revise setting sfDirty on horizontal velocity as well.
* Switch to AxisVelocity (vertical), accounting for + and -.
* Use a LinkedList for storing past locations (prevents overriding if
t_last = t_now, also allows storing differences there right away).
* Calculate the yaw difference vs. the maximally possible value (180).
* Add switching the target as an extra weight.
The workarounds in InteractRayTracing and using multiple
reference-targets in Visible have all been removed in favor of using the
actual looking direction for ray-tracing.
On quick testing, there remain false positives, allowing to somewhat
escalate violation levels, if intended to. On normal playering false
positives seem to happen very near the very edges between blocks on
occasion.
* More tests for PassableRayTracing (room, rays from outside).
* Alter InteractRayTracing to account for the block interacted with.
* Added tests for InteractRayTracing.
Problems:
* RayTracing may end x-th digit off target, thus in the wrong block.
Suggested fix is to keep correcting t by the absolute coordinates of the
blocks, i.e. calculate the absolute position rather than adding up.
* InteractRayTracing with strict set to false (like in the
blockinteract.visible check) will be too lenient with 1-thick wall
setups and fail test cases.
