Within BlockProperties BlockCache and IBlockCacheNode ("read only") get
passed, removing id/data/shape from arguments. If a property is not set
in the node, it'll be fetched from the block cache, but the node is not
updated from outside the BlockCache. For subsequent calls, the node
would be updated by the block cache, if it isn't a node stored by the
BlockChangeTracker from an earlier time, and similar.
This way, opportunistic passable checking can be implemented, by
switching to cached nodes instead of id/data/shape arguments with lazy
fetching from BlockCache.
The name IBlockCacheNode seems to be appropriate, since we'll pass it
alongside with a BlockCache anyway.
Cross-world teleport to the end issue: set back hard, if the player
moves to the position they set off from the last world, which seems to
be a bug with some server types/versions at present (!?).
Some packets arrive with a null world for a player, possibly sent by
plugins - thus attempt to use a stored world name.
This is just a hot fix attempt.
Attempt to enable workarounds for lily pads with servers that support
multiple client versions. Add to the configuration at
compatibility.blocks.overrideflags:
WATER_LILY: default+ign_passable+ground_height+height8_1
HEIGHT8_1 just means 1/8 height (0.125).
The ALLOW_LOWJUMP flag was intended to be used in case of
ground_height+height100 or the like leading to issues with
sprint-jumping due to the low jump detection, however other special
casing checks for bunny hopping let this still fail (less than before,
but still), thus this flag might get removed. Keeping it for now, to
provide some kind of toolkit.
Technically, tracking actual speed / base speed seems promising, done
here via using the liftOffEnvelope that is maintained anyway, adding a
counter and sum value. [Base speed is something like the allowed speed,
without accounting for specialties like bunny hopping.]
Limits are checked for moving in ground+air or water+air and are
currently hard-coded. This simplistic first-step-in may easily yield all
sorts of false positives and other random issues, handle with care.
Can't judge side effects, concerning other passable like tests telling
the head to be inside a block by the micro margin, while passable allows
such a move now.
Not sure if this really pays, if most people use protocol-support
plugins that limit packets anyway. There could be some future use, e.g.
generic rate limiting with configurable implementation.
Other:
* New methods for RawConfigFile+ConfigManager to check for
AlmostBooleanS.
* Add all net check permissions to plugin.yml.
