Talk:Pre-release protocol - Revision history

imported>JochCool: /* How does the Map Data packet work now? */ formatting fix

2021-01-12T18:36:24Z

How does the Map Data packet work now?: formatting fix

← Older revision		Revision as of 18:36, 12 January 2021
Line 46:		Line 46:
	== How does the Map Data packet work now? ==		== How does the Map Data packet work now? ==

	It says that the icons cound field is only present if "Tracking Position" is true. But how does the number of icons get determined now then? By the length of the packet? ~~&horbar;~~[[User:JochCool\|JochCool]] ([[User talk:JochCool\|talk]]) 18:35, 12 January 2021 (UTC)		It says that the icons cound field is only present if "Tracking Position" is true. But how does the number of icons get determined now then? By the length of the packet? ―[[User:JochCool\|JochCool]] ([[User talk:JochCool\|talk]]) 18:35, 12 January 2021 (UTC)

imported>JochCool: /* How does the Map Data packet work now? */ new section

2021-01-12T18:35:37Z

How does the Map Data packet work now?: new section

← Older revision		Revision as of 18:35, 12 January 2021
Line 43:		Line 43:

	Ive only done some basic testing and if anyone can confirm that, I would suggest adding that to the docs.		Ive only done some basic testing and if anyone can confirm that, I would suggest adding that to the docs.

			== How does the Map Data packet work now? ==

			It says that the icons cound field is only present if "Tracking Position" is true. But how does the number of icons get determined now then? By the length of the packet? &horbar;[[User:JochCool\|JochCool]] ([[User talk:JochCool\|talk]]) 18:35, 12 January 2021 (UTC)

imported>Paulomart: /* 1.15 Chunk Biome Data Changes */ new section

2019-11-27T20:07:19Z

1.15 Chunk Biome Data Changes: new section

← Older revision		Revision as of 20:07, 27 November 2019
Line 37:		Line 37:

	Thanks		Thanks

			== 1.15 Chunk Biome Data Changes ==

			It seems like the new "Biomes" field in 0x22 replaces the Biomes field in https://wiki.vg/Chunk_Format#Data_structure

			Ive only done some basic testing and if anyone can confirm that, I would suggest adding that to the docs.

imported>Mct: /* Please commit before you change old packets */ new section

2014-07-04T13:20:57Z

Please commit before you change old packets: new section

← Older revision		Revision as of 13:20, 4 July 2014
Line 29:		Line 29:
	FF-FE-AE-66- Z?		FF-FE-AE-66- Z?
	6B-D5-00-35-71-00-00-00-00-00-00-10-00-21-01-2C-82-00-52-00-00-02-D5-03-00-66-41-99-99-9A-47-00-00-00-00-08-00-09-00-0A-7F-7F		6B-D5-00-35-71-00-00-00-00-00-00-10-00-21-01-2C-82-00-52-00-00-02-D5-03-00-66-41-99-99-9A-47-00-00-00-00-08-00-09-00-0A-7F-7F

			== Please commit before you change old packets ==

			Whenever a previously existing packet has been changed please add it to this page and save the old version before you change it.

			This will make it easier to see what has changed.

			Thanks

imported>Mct: /* Protocol Change 13w21a */

2014-05-23T23:25:57Z

Protocol Change 13w21a

← Older revision		Revision as of 23:25, 23 May 2014
Line 4:		Line 4:
	Thanks		Thanks
	:[[User:vbisbest\|vbisbest]] 12:39, 29 May 2013 (EST)		:[[User:vbisbest\|vbisbest]] 12:39, 29 May 2013 (EST)

			0x2C is known as Spawn Global Entity, like thunderbolt

			--[[User:Mct\|Mct]] ([[User talk:Mct\|talk]]) 23:25, 23 May 2014 (UTC)

	==Chunk Deallocation==		==Chunk Deallocation==

imported>Mct: /* Spawn player has changed */ new section

2014-05-23T22:58:46Z

Spawn player has changed: new section

← Older revision		Revision as of 22:58, 23 May 2014
Line 12:		Line 12:

	:[[User:Shoghicp\|Shoghicp]] 12:15, 30 July 2012 (MST)		:[[User:Shoghicp\|Shoghicp]] 12:15, 30 July 2012 (MST)

			== Spawn player has changed ==

			This is what I got as a spawn player packet.
			Packet size prefix is not included here and the stream is the complete packet.

			0C-Packet ID
			AF-7B- Entity ID varint encoded
			68-F1-F7-49-8B-9F-37-27-86-3A-B1-4E-EA-1C-5C-83- My guess, UUID binary, was previously a string
			FF-FF-F1-B5- X?
			00-00-08-D0- Y?
			FF-FE-AE-66- Z?
			6B-D5-00-35-71-00-00-00-00-00-00-10-00-21-01-2C-82-00-52-00-00-02-D5-03-00-66-41-99-99-9A-47-00-00-00-00-08-00-09-00-0A-7F-7F

imported>Vbisbest: /* Chunk Deallocation */

2013-05-29T04:36:51Z

Chunk Deallocation

← Older revision		Revision as of 04:36, 29 May 2013
Line 1:		Line 1:
			==Protocol Change 13w21a==
			It appears there may be a new packet in 13w21a. It may be a 2C packet. Anyone have any insight into the changes for this snapshot?

			Thanks
			:[[User:vbisbest\|vbisbest]] 12:39, 29 May 2013 (EST)

	==Chunk Deallocation==		==Chunk Deallocation==
	In the discussion of the removal of the '''Chunk Allocation Packet''', the article says: "To deallocate memory you need to send a MapChunk packet, which only contains biome data for plains(all biome bytes set to 1)." According to my testing of a custom client with a vanilla Minecraft 1.3 server, when a chunk goes out of range the server actually sends a Chunk Data (0x33) packet ground_up_continuous=true, primary_bit_map=0, add_bit_map=0, and real actual biome data (in my case it was mostly plains and some desert). This suggests that the sentence should be edited to: "To deallocate memory you need to send a Chunk Data (0x33) packet which only contains biome data.". If someone else can confirm this, please post here. I think this makes more sense, and it's easier to test for in the client because you don't have to look at the compressed data at all.		In the discussion of the removal of the '''Chunk Allocation Packet''', the article says: "To deallocate memory you need to send a MapChunk packet, which only contains biome data for plains(all biome bytes set to 1)." According to my testing of a custom client with a vanilla Minecraft 1.3 server, when a chunk goes out of range the server actually sends a Chunk Data (0x33) packet ground_up_continuous=true, primary_bit_map=0, add_bit_map=0, and real actual biome data (in my case it was mostly plains and some desert). This suggests that the sentence should be edited to: "To deallocate memory you need to send a Chunk Data (0x33) packet which only contains biome data.". If someone else can confirm this, please post here. I think this makes more sense, and it's easier to test for in the client because you don't have to look at the compressed data at all.

imported>Shoghicp at 19:15, 30 July 2012

2012-07-30T19:15:40Z

← Older revision		Revision as of 19:15, 30 July 2012
Line 3:		Line 3:
	--[[User:DavidEGrayson\|DavidEGrayson]] 23:33, 28 July 2012 (MST)		--[[User:DavidEGrayson\|DavidEGrayson]] 23:33, 28 July 2012 (MST)
	:In my client I check for the ground_up_continuous=true, primary_bit_map=0, add_bit_map=0. The biome data is sent because it is always sent.		:In my client I check for the ground_up_continuous=true, primary_bit_map=0, add_bit_map=0. The biome data is sent because it is always sent.
	I don't know if it's real or not, but you don't need to check it		:I don't know if it's real or not, but you don't need to check it

	[[User:Shoghicp\|Shoghicp]] 12:15, 30 July 2012 (MST)		:[[User:Shoghicp\|Shoghicp]] 12:15, 30 July 2012 (MST)

imported>Shoghicp: Response

2012-07-30T19:15:22Z

Response

← Older revision		Revision as of 19:15, 30 July 2012
Line 1:		Line 1:
			==Chunk Deallocation==
	In the discussion of the removal of the '''Chunk Allocation Packet''', the article says: "To deallocate memory you need to send a MapChunk packet, which only contains biome data for plains(all biome bytes set to 1)." According to my testing of a custom client with a vanilla Minecraft 1.3 server, when a chunk goes out of range the server actually sends a Chunk Data (0x33) packet ground_up_continuous=true, primary_bit_map=0, add_bit_map=0, and real actual biome data (in my case it was mostly plains and some desert). This suggests that the sentence should be edited to: "To deallocate memory you need to send a Chunk Data (0x33) packet which only contains biome data.". If someone else can confirm this, please post here. I think this makes more sense, and it's easier to test for in the client because you don't have to look at the compressed data at all.		In the discussion of the removal of the '''Chunk Allocation Packet''', the article says: "To deallocate memory you need to send a MapChunk packet, which only contains biome data for plains(all biome bytes set to 1)." According to my testing of a custom client with a vanilla Minecraft 1.3 server, when a chunk goes out of range the server actually sends a Chunk Data (0x33) packet ground_up_continuous=true, primary_bit_map=0, add_bit_map=0, and real actual biome data (in my case it was mostly plains and some desert). This suggests that the sentence should be edited to: "To deallocate memory you need to send a Chunk Data (0x33) packet which only contains biome data.". If someone else can confirm this, please post here. I think this makes more sense, and it's easier to test for in the client because you don't have to look at the compressed data at all.
	--[[User:DavidEGrayson\|DavidEGrayson]] 23:33, 28 July 2012 (MST)		--[[User:DavidEGrayson\|DavidEGrayson]] 23:33, 28 July 2012 (MST)
			:In my client I check for the ground_up_continuous=true, primary_bit_map=0, add_bit_map=0. The biome data is sent because it is always sent.
			I don't know if it's real or not, but you don't need to check it

			[[User:Shoghicp\|Shoghicp]] 12:15, 30 July 2012 (MST)

imported>DavidEGrayson at 17:06, 30 July 2012

2012-07-30T17:06:37Z

← Older revision		Revision as of 17:06, 30 July 2012
Line 1:		Line 1:
	In the discussion of the removal of the '''Chunk Allocation Packet''', the article says: "To deallocate memory you need to send a MapChunk packet, which only contains biome data for plains(all biome bytes set to 1)." According to my testing of a custom client with a vanilla Minecraft 1.3 server, when a chunk goes out of range the server actually sends a Chunk Data (0x33) packet ground_up_continuous=true, primary_bit_map=0, add_bit_map=0, and real actual biome data (in my case it was mostly plains and some desert). This suggests that the sentence should be edited to: "To deallocate memory you need to send a Chunk Data (0x33) packet which only contains biome data.". If someone else can confirm this, please post here. I think this makes more sense, and it's easier to test for in the client because you don't have to look at the compressed data at all.		In the discussion of the removal of the '''Chunk Allocation Packet''', the article says: "To deallocate memory you need to send a MapChunk packet, which only contains biome data for plains(all biome bytes set to 1)." According to my testing of a custom client with a vanilla Minecraft 1.3 server, when a chunk goes out of range the server actually sends a Chunk Data (0x33) packet ground_up_continuous=true, primary_bit_map=0, add_bit_map=0, and real actual biome data (in my case it was mostly plains and some desert). This suggests that the sentence should be edited to: "To deallocate memory you need to send a Chunk Data (0x33) packet which only contains biome data.". If someone else can confirm this, please post here. I think this makes more sense, and it's easier to test for in the client because you don't have to look at the compressed data at all.
	--[[User:DavidEGrayson\|DavidEGrayson]] 23:33, 28 July 2012 (MST)		--[[User:DavidEGrayson\|DavidEGrayson]] 23:33, 28 July 2012 (MST)


	~~According to the [https://github.com/sadimusi/mc3p/blob/master/mc3p/messages.py#L336 mc3p proxy server code], the last field of packet 0x36 (Block Action) is a short. I think the article is wrong.~~
	~~--[[User:DavidEGrayson\|DavidEGrayson]] 10:57, 29 July 2012 (MST)~~