[SPIGOT-2549] Respawn packet has incorrect encoding Created: 23/Jul/16  Updated: 24/Jul/16  Resolved: 23/Jul/16

Status: Resolved
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Dorquemada Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: Respawn, spigot,
Environment:

OS: Linux, MS Client: Wurst 4.0, Vanilla 1.10.2, Server: 64.34.190.101:28965



 Description   

When receiving Respawn (0x33, client-bound) packets from a Spigot 1.10 server, these are encoded incorrectly. The packet format should be as follows:
4 bytes Int: dimension (-1:nether, 0:overworld, 1:end)
1 byte Char: difficulty (0:peaceful, 1:easy, 2:normal, 3:hard, bit 3 (+8): hardcore)
1 byte Char: gamemode (0:survival, 1:creative, 2:adventure, 3:spectator)

Examples for a Respawn packet received from various servers:

  • from a Spigot 1.10 server (64.34.190.101:28965):
    00 00 00 0b 00 01 07 64 65 66 61 75 6c 74 .......default
    dimension=11 (???), difficulty=peaceful, gamemode=creative
  • from a Vanilla 1.10 server (locally installed):
    ff ff ff ff 01 01 04 66 6c 61 74 .......flat
    dimension=-1 (nether), difficulty=1 (easy), gamemode=1 (creative)

00 00 00 00 01 01 04 66 6c 61 74 .......flat
dimension=0 (overworld), difficulty=1 (easy), gamemode=1 (creative)

  • from a Waterfall 1.8/1.9/1.10 server (2b2t.org):
    00 00 00 01 00 00 07 64 65 66 61 75 6c 74 .......default
    dimension=1 (end), difficulty=0 (peaceful), gamemode=0 (survival)

ff ff ff ff 00 00 07 64 65 66 61 75 6c 74 .......default
dimension=-1 (nether), difficulty=0 (peaceful), gamemode=0 (survival)

ff ff ff ff 03 00 07 64 65 66 61 75 6c 74 .......default
dimension=-1 (nether), difficulty=3 (hard), gamemode=0 (survival)

My guess is that Spigot 1.10 sends the values of dimension,difficulty,gamemode as shorts, which would interpret the output from the first example as dimension=0 (overworld), difficulty=11 (hard+hardcore), gamemode=0 (survival), while it should encode them as int,byte,byte (in both cases followed by a string)



 Comments   
Comment by Dorquemada [ 24/Jul/16 ]

I agree this issue is likely caused by some plugins running on that server, as it's the only place where this behavior occurs. I was not able to detect it on any other Spigot 1.10 server.
In my case however, I always received dimension as 0000000b when spawning on this affected server.
Sorry for inconvenience

Comment by md_5 [ 24/Jul/16 ]

Oh and for the avoidance of any doubt, that > 10 "internal IDs" mentioned by Black Hole are not sent over the wire.
I created a new world using the MultiVerse plugin and teleported to it:

ffffffff01010764656661756c74
net.minecraft.network.play.server.SPacketRespawn@15cd52f[dimensionID=-1,difficulty=EASY,gameType=CREATIVE,worldType=net.minecraft.world.WorldType@48e490a5]
0000000001010764656661756c74
net.minecraft.network.play.server.SPacketRespawn@bb5f658[dimensionID=0,difficulty=EASY,gameType=CREATIVE,worldType=net.minecraft.world.WorldType@48e490a5]

I think what you are seeing is either a result of 1) a buffer corruption/overrun in your client, or 2) a function of the copious unsupported plugins running on the abovementioned server (that hack into Spigot internals or perform protocol level manipulation, see: ProtocolLib)

Comment by md_5 [ 23/Jul/16 ]

Oh and I dumped the packets from the above server (64.34.190.101:28965) and didn't see what you described:

0000000000010764656661756c74
0000000001010764656661756c74
ffffffff00010764656661756c74
Comment by md_5 [ 23/Jul/16 ]

Spigot does not modify the respawn packet at all.
Custom worlds will have a higher dimension ID.
SkyLight data is not a function of world ID, but rather a function of if the world actually has sky light data (ie: is an overworld dimension). The Vanilla client and Minecraft Forge (which even supports custom dimensions) are the same in this respect.

A dump of the respawn packet on my server (no plugins and hence no custom dimensions), reads as follows:
net.minecraft.server.PacketPlayOutRespawn@59e7a23c[a=0,b=EASY,c=CREATIVE,d=net.minecraft.server.WorldType@2f02ec12]

Comment by Dorquemada [ 23/Jul/16 ]

Well, the specific issue is that the ChunkData packet has an optional data array 'skylight' whether or not is this array present has to be derived from the current dimension. If the dimension is 0 (overworld), then the skylight is present, otherwise it is not. If you make a wrong assumption, the packet will be decoded incorrectly.

If Spigot supports other dimensions, that's fine, but in the case the dimension is not 0, you should not include the skylight data in the ChunkData packets.

What specifically triggered the investigation about this issue can be seen here: http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-tools/2599886-mcbuild-a-custom-minecraft-client-with-auto-build?page=3
A custom client of mine has been failing an assertion while decoding ChunkData packets from one specific server running Spigot 1.10

Comment by Black Hole [ 23/Jul/16 ]

Spigot can handle more than the three default worlds. They are assigned dimension ids starting with 10.

Is there any real issue with those dimension ids?

Comment by Dorquemada [ 23/Jul/16 ]

Note that the correct information about the dimension which is sent in Respawn and JoinGame packets is necessary to correctly decode ChunkData packets. Without correct dimension information, it can't be reliably determined whether the packets contain the skylight info or not - this could explain several bugs related to lighting being tracked right now.

Generated at Thu Mar 28 22:40:58 UTC 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.