this fixes rendering of underwater TNT and possibly other chemistry blocks.
There doesn't seem to be a shortcut for this, and BDS also appears not to account for
this requirement, which is why underwater TNT also doesn't have the right texture in BDS.
fixes#6494
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
we were already doing this in some places but not others. So inconsistent...
while this doesn't fix the root cause of #5128, it should nonetheless fix#5128
as well as not destroying player data on unknown items, which was a frequent
annoyance when switching between branches during PR testing.
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.
