Talk:Chunk Format: Difference between revisions
Jump to navigation
Jump to search
imported>Barneygale No edit summary |
imported>Xenotoad →1.8 Chunk Format: new section |
||
Line 2: | Line 2: | ||
[[User:Xoft|Xoft]] ([[User talk:Xoft|talk]]) 09:51, 27 December 2012 (MST) | [[User:Xoft|Xoft]] ([[User talk:Xoft|talk]]) 09:51, 27 December 2012 (MST) | ||
:Fixed! [[User:Barneygale|Barneygale]] ([[User talk:Barneygale|talk]]) 08:03, 8 January 2013 (MST) | :Fixed! [[User:Barneygale|Barneygale]] ([[User talk:Barneygale|talk]]) 08:03, 8 January 2013 (MST) | ||
== 1.8 Chunk Format == | |||
The section describing how the chunk data is stored is... either completely wrong or very misleading. By reading it I got the idea that the data was stored like this: | |||
BVVLSbBVVLSbBVVLSb... | |||
(3 sections) | |||
where B: block and metadata array | |||
V: varint (1st one for # of bits, 2nd one for # of elements) | |||
L: light data | |||
S: skylight data (may or may not be there) | |||
b: biome data (for each section? wat?) | |||
when in reality it's stored like this: | |||
BBBBBLLLLLSSSSSb | |||
(5 sections) | |||
where B: block and metadata array | |||
L: light data | |||
S: skylight data | |||
b: biome data (only one this time) | |||
and there are no varints. |
Revision as of 22:45, 30 December 2015
Actually the 0x33 Map chunk is still used by vanilla 1.4.6 server to send individual chunks; I'm seeing this packet in the protocol disassembly when the player is moving across chunk boundaries. I personally think the server sends 0x38 only when entering a world (start of session or transition to / from the Nether / End) and otherwise it sends 0x33 for each individual chunk that's coming into player's viewdistance. Xoft (talk) 09:51, 27 December 2012 (MST)
- Fixed! Barneygale (talk) 08:03, 8 January 2013 (MST)
1.8 Chunk Format
The section describing how the chunk data is stored is... either completely wrong or very misleading. By reading it I got the idea that the data was stored like this:
BVVLSbBVVLSbBVVLSb... (3 sections) where B: block and metadata array V: varint (1st one for # of bits, 2nd one for # of elements) L: light data S: skylight data (may or may not be there) b: biome data (for each section? wat?)
when in reality it's stored like this:
BBBBBLLLLLSSSSSb (5 sections) where B: block and metadata array L: light data S: skylight data b: biome data (only one this time)
and there are no varints.