This checks the following things:
- Validity of UTF-8 encoding of title, author, and page content
- Maximum soft and hard lengths of title, author, and page content (soft
limits may be bypassed by uncancelling PlayerEditBookEvent; hard
limits may not be bypassed)
- Maximum number of pages. Books with more than 50 pages may still be
edited, but may not have new pages added.
This checks the following things:
- Validity of UTF-8 encoding of title, author, and page content
- Maximum soft and hard lengths of title, author, and page content (soft
limits may be bypassed by uncancelling PlayerEditBookEvent; hard
limits may not be bypassed)
- Maximum number of pages. Books with more than 50 pages may still be
edited, but may not have new pages added.
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
avoid the overhead incurred by clear() and setItem(), because in internalSetContents(), we already have no listeners or viewers to talk to anyway, so this is just spamming shit into /dev/null.
