the current data management system uses case-insensitive names, so we can't allow different players with the same name in different cases to join, or we will have duplication exploits.
This typically only applies to offline servers, since Xbox Live doesn't permit reuse of a username, same case or otherwise.
closes#4965
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.
closes#4896closes#4898
this is not completely consistent with client-side predictions due to a bug in the client, which I believe is a problem limited to the legacy transaction system.
this is a bit less sophisticated than the way we do it with BlockFactory, but this shouldn't usually have any relevance anyway - it's only used for correcting bogus states.
this does come at a performance cost, but is necessary for metadata expansion.
we finally concede that this is not going to happen without BC breaks, however small they might be ...
when we expand the metadata range, having a fixed array here will present some problems due to significantly increased memory footprint (2x for every bit added).
the second parameter to this callback is the OLD slots, not the changed slots. This means that ALL slots are included, including empty and unchanged slots.
