Jury is out on whether they should be able to pick blocks at all, or be considered to have infinite resources, but this solution has been used in a few other places already anyway, so it can be cleaned up another time.
closes#4626
this does change the behaviour of getCurrentWindow() during InventoryCloseEvent, but no one should be using that anyway, since InventoryCloseEvent->getInventory() exists.
fixes#5021 and probably a bunch of other inventory related glitches
When the server initiates a window close, it does so by sending a ContainerClose to the client, which causes the
client to behave as if it initiated the close itself. It responds by sending a ContainerClose back to the server,
which the server is then expected to respond to.
Sending the client a new window before sending this final response creates buggy behaviour on the client, which
is problematic when switching windows. Therefore, we defer sending any new windows until after the client
responds to our window close instruction, so that we can complete the window handshake correctly.
This is a pile of complicated garbage that only exists because Mojang overengineered the process of opening and
closing inventory windows.
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.
in PM3, this was done by implicitly relying on the client to send a MobEquipmentPacket selecting the same hotbar slot when the slot contents changes.
In PM4, we avoid relying on this, and fire the event directly when the listener detects a held slot change.
This ensures that the behaviour remains consistent regardless of what the client starts doing in the future.
closes#4905
mb_strlen() is O(n), whereas strlen() is O(1). If we receive very large chat messages (e.g. 2 MB), mb_strlen() will take a very long time to return a result (around 8ms on my machine).
Since the max size of a UTF-8 character is 4 bytes (according to standard), we can use strlen() with 4x the char limit to gate it and prevent this from happening.
Due to the way positions are updated over the network, we only see the end result of a movement and not its preceding actions. In addition, we don't know for sure whether the MCPE collision checks work the same exact way as PM.
TL;DR: It's possible for the client to capture and send a movement frame after they collided with a step and then already moved forward from it some distance, resulting in a weird arc pattern.
This PR checks the range between the old and new positions for collision boxes to ensure that all possible areas are checked for detecting fall damage.
This has been tested and successfully resolves various issues involving running down stairs:
- missing sounds
- random fall damage
