Paper
Paper copied to clipboard
Fix GlobalPalette serialized size
Within chunk packets, there is a new ByteBuf allocated with pre-calculated size based on the chunk section's non-air blocks and their block palettes. The global palette size returns 1 instead of 0 bytes and the buffer is needlessly extended - which doesn't cause any issues or warnings, since this is a special allocated buf inside of a packet, but still causes the mismatch in expected length and actual content (= being left with readableBytes > 0 despite all actual data having ended), annoying in custom protocol reading
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in a long time. If the issue still applies to the most recent supported version, please open a new issue referencing this original issue.
Related to this topic: There is another case where a wrong serialized size may occur.
public class PalettedContainer<T> implements PaletteResize<T> {
...
public int getSerializedSize() {
return 1 + this.palette.getSerializedSize() + FriendlyByteBuf.getVarIntSize(this.storage.getSize()) + this.storage.getRaw().length * 8;
}
...
}
In this code FriendlyByteBuf.getVarIntSize(this.storage.getSize()) should actually be FriendlyByteBuf.getVarIntSize(this.storage.getRaw().length). I have opened a PR for this a long time ago here #872. However, a wrong conclusion has been made there in my opinion. It might be worth to reconsider this and adding it to this patch.
Yeah as mentioned by stonar, it might be nice to have a patch that both covers these size method issues.
Closing.
When discussing it internally it was brought up that it could technically cause issues if plugins do any stupid packet reading in this area. It's probably better to just bump this with mojang.
For reference, this has been fixed in 23w31a.