the intent of this was noble (to make sure nothing was missed), but in practice throwing
errors on this stuff is just a pain in the ass. We don't actually need to care if the
properties are not used, since it doesn't affect the decoding (like it would for
a missing packet field), so the only reasons to complain are for BedrockProtocol to
have a complete picture of the protocol, and to make sure we're not discarding useful
information.
Log a warning in these cases instead, which should be noticed by developers without
being an unnecessary problem for users.
closes#6816
This implements ext-encoding only in high-level network I/O (only BedrockProtocol and stuff implemented in PM) and read-only data.
This should net a significant performance advantage while being low-risk in the case of critical issues with the extension. Any problems affecting protocol won't do permanent damage while being fairly easy to debug.
Next passes will integrate ext-encoding versions of RakLib, RakLibIpc and NBT, as well as generally using ext-encoding for writeable data.
this now throws in PHP 8.4. Previously it returned the same as php_uname(a).
Presumably the intent was to capture the CPU arch and not a repeat of the machine field.
closes#6811
if the prediction was a fail, we can assume that the client didn't do anything visual on its end,
which avoids the need to resend blocks.
This fixes block lag when towering as discussed in #6803.
The more general issue in #6803 remains unresolved (that the server's block resyncing may overwrite
additional client side predictions if it places a block before the server's resync for the initial
placement arrives), but that's more complicated to fix and I'm not convinced on the correct method
to resolve it yet.
In any case, this change nets a decent improvement for everyone, regardless.
closes#6778
honestly, we could just stop checking the window ID entirely, considering the need for delaying and waiting
for window close acks, it seems useless at this point...
hasNamedTag() rebuilds the NBT from item properties to decide if there's any NBT.
This is a waste of resources when we then fetch the tag to encode anyway.
TypeConverter: Strip unnecessary NBT from clientbound items
Item containers like shulker boxes, or chests with block entity data obtained with ctrl+middle click, will often have extremely large NBT payloads.
This problem gets exponentially worse in cases where it's possible to nest inventories, as in #4665.
We can't easily address this at the core level, because tiles are not able to exist within items (due to position requirement)
so we don't have a good way to avoid this useless NBT in the first place. However, we can strip it before the item is sent to
the client, which dramatically reduces the network costs of such items, as well as removing any reason the client could have
to send such enormous items to the server.
A fully loaded shulker box with written books now takes only 5-6 KB on the wire instead of ~1 MB, which is a substantial improvement.
Dealing with this in a less hacky way is currently blocked on #6147.
* Deprecate BaseSign get/set/updateText(), add get/set/updateFaceText() which accepts true/false for front/back
* add isFrontFace() to SignChangeEvent
* add optional frontFace to Player::openSignEditor()
* add BaseSign::getFacingDegrees() and getHitboxCenter() which need to be implemented by subclasses
