Conversation
A vector longer than 3 carries scale >> 2 in a trailing var-int. The scale is clamped to 1.7179869183e10, so that var-int runs up to 2^32 - 1, and LpVec3.read masks it back to unsigned: scale |= ((long)VarInt.read(input) & 4294967295L) << 2 readVarInt returns an int, so from 2^31 up (a component of 8589934592 or more) the scale came out negative: every component flipped sign and the magnitude collapsed, and the value no longer wrote back to the bytes it was read from. The writer was already right. Adds vanilla 26.3 bytes for scale >> 2 at each var-int length, either side of 2^31 and at the clamp.
26.3 replaced the three i16 deltas and the trailing onGround boolean of
rel_entity_move and entity_move_look with a VecDelta behind a packed
var-int:
writeVarInt(entityId)
writeVarInt((onGround ? 1 : 0) | stepCount << 1)
VecDelta.write(...)
A step count of 0 is VecDelta.Linear, the same three i16 as before.
Anything higher is VecDelta.Stepped, that many
{ varint ticks, i16, i16, i16 } records. The count comes out of the
var-int by a shift, which a protocol definition cannot express, so
minecraft-data declares the field as a vecDelta native and the type
reads and writes the var-int together with the delta it governs.
The value is { onGround, dX, dY, dZ } or { onGround, steps: [{ ticks,
dX, dY, dZ }] }, keeping the field names those packets had.
Tested against the bytes a vanilla 26.3 server writes for both forms,
and through an interpreted and a compiled protocol since the type is
registered for each separately.
minecraft-data#1267 moved the 26.1 item fields that cannot be empty (advancement icons, use_remainder, bundle and container contents) onto a new ItemStackTemplate type. packetTest builds every packet from a table of values per type and had none for it, so 26.1 packet_advancements threw "No value for type ItemStackTemplate" before writing anything. It takes the same fields as a filled Slot, so reuse that value.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three datatype fixes found by round-tripping packets generated by a vanilla 26.2 / 26.3 server byte-for-byte through the protocol. Each commit stands alone and comes with unit tests built on real vanilla bytes.
rel_entity_move/entity_move_looklayout.onGroundand the step count share one var-int, which a protocol definition cannot split apart. The value is{ onGround, dX, dY, dZ }or{ onGround, steps: [{ ticks, dX, dY, dZ }] }.packetTesthad no value forItemStackTemplate(minecraft-data#1267), so 26.1packet_advancementsthrew before writing anything.