LordExecuter
- LordExecuter
- lordexecuter
- Europe/Stockholm
- Yes
- No
MC-132361
In the Clientbound respawn and Login packets there is an additional field variable in 1.16-pre6 which should contain the previous gamemode.
The previous gamemode is being written to the Netty buffer as signed byte, so is the current gamemode.
Both those values are then *
read as unsigned bytes* by the client.This will produce incorrect results.
Since this snapshot there is the NOT DEFINED gamemode ID -1.
Sending -1 over this will have the client read 255 instead of -1 because of the unsigned type reading.
In 1.16 Prerelease 6 there was a field added to both the Login/Join Game packet and the Respawn Clientbound packets
These packets now contain the previous gamemode ID of the player.
Alsongside this; Gamemode ID -1, (Not defined gamemode) was added.There is an issue with this however.
Both the current and past gamemodes are written to the netty network buffer by their integer ID.
That's -1 for Not defined.
They are written as *signed bytes*The client then gets those and reads them as *unsigned bytes*
This does NOT create an issue were all gamemode IDs always positive (prior to this they were)
But since this snapshot there is a negative gamemode ID which can NEVER be read correctly by thisSending the client -1 as ID will make it read 255 from the buffer.
Solution: Read both gamemode IDs as signed bytes, like they should be read
Still not fixed/ betapre-10
@Earthcomputer It’s true I did not research how this negatively impacts the gameplay, and frankly this wasn’t my goal.
I simply reported the obvious inconsistency that occurs when a signed primitive type is read as unsigned type.
It is clear to me however that this creates uncontrolled behavior.
Reading it as an unsigned type would only make sense if you desperately needed the extra positive bit to convey even larger numbers, in which case, it would still be better not to use byte at all for this.
Still in 1.16 Pre-release 8.