this is a sucky solution but it works well enough for this scenario.
From my research it appears that while the client-side MovementInterpolator is active on the client and hasn't yet reached its target, any teleport sent during the lerp will get overridden by the lerp.
This appears to last 3-4 ticks (about 150-200 ms) which explains why this can be reproduced by stopping movement just before the ender pearl lands (human reaction times would make the reproduction unreliable otherwise).
Things to note:
- All entities are affected by this bug.
- MovePlayerPacket appears not to have the problem, but we can't use it because it doesn't work for non-players.
- MoveActorAbsolute and MoveActorDelta are both handled by the same code and will have the same lerping bug.
This is the cleanest solution I could come up with.
- The following events have been added:
- PlayerToggleGlideEvent
- PlayerToggleSwimEvent
- The following API methods have been added:
- Entity->getSize()
- Living->isSwimming()
- Living->setSwimming()
- Living->isGliding()
- Living->setSwimming()
- Player->toggleSwim()
- Player->toggleGlide()
this->size refers to the scaled height, but the client wants the base (unscaled) size in these properties.
This caused immense lag when, for example, setting the scale of a player to 10, because their collision box would become 180 by 60, instead of the expected 18 by 6.
to be consistent with Position::__construct() and Location::fromObject() (although Location::fromObject() has no choice, thanks to the anti-feature known as late static binding ...)
the intent of these hacks was to break cyclic references to avoid having objects lingering in memory. However, all of the stuff that's being removed in this commit no longer has any effect anyway, due to the fact that these things don't circularly reference each other anymore. Notably, Tile inventories now keep Position instead of a Tile ref.
it's now the World's responsibility to manage adding/removing entities from appropriate chunks. Entities no longer know or care that chunks exist.
Entity->checkChunks() remains as-is for backwards compatibility - now it just calls the world to sync its position.
previously this created an empty chunk for the entity to hang around in until the terrain was generated, but that's problematic for several reasons, most importantly the fact that non-generated chunks are not saved.
