Chunk

A chunk is a 16×16 segment of a world. Chunks are the method used by the game to divide maps into manageable pieces. They are further divided in 16-block tall sections, which are also often called "subchunks".

Description

Chunks are 16 blocks wide by 16 blocks long. They extend from the bottom void of the world all the way up to the build limit. In the Overworld, their height is 384 blocks, and they have 98,304 blocks total. In the Nether, their heights are 256 blocks in Java Edition and 128 blocks in Bedrock Edition. In the End, their height is 256 blocks.

Chunks generate around players when they first enter the world. In Java Edition, the generating and loading progress are displayed on the loading world screen. As players wander around the world, new chunks generate as needed.

Chunks generate with the help of the map seed, which means that each chunk generates largely the same if you would use the same seed again, as long as the map generator and version number remain the same; however, basic world information is not the only information that contributes to the generation of a chunk. if an entity that can load chunks, including the player, loads from a certain direction the chunk may generate with slight variations such as the direction or variant of certain world elements, or very slight changes to the shape of the world itself.

Chunk loading

Since Minecraft worlds are 30 million blocks in each cardinal direction and contain an extreme number of chunks, the game loads only certain chunks in order to make the game playable. Unloaded chunks are unprocessed by the game and do not process any of the game aspects.

The game always loads the entire chunk when it decides a chunk needs to be processed. The division into sections is only used for display purposes (e.g. to limit the amount of data to transfer to the game client) and certain game mechanics (e.g. village mechanics).

Java Edition chunk loading

Tickets

Loading starts when a chunk receives a ticket. All loaded chunks originate from the ticket. Each load ticket has three properties: Ticket type, load level, and ticks remaining. The initial time to live of a ticket is based on the ticket type.

Level and load type

Levels are numbers that determine what load type the chunk is in. A lower level represents a higher load type. For a given chunk, it may get different levels from different tickets, but only the lowest level matters.

Load levels range from 22 to 44 in regular gameplay, while only 22 to 33 are relevant to chunk loading. Load levels less than 22 are valid but possible only with a modded game. Load levels above 44 are instantly unloaded in vanilla.

There are four chunk load types; each load type has different properties. This excludes unloaded chunks.

Level propagation

Load levels "propagate" or flow from source chunk with a ticket to neighboring chunks, but each time it increases its level by 1 until the maximum of 44.

The chunks that get load level from level propagation activate the assigned load type.

Ticket types

This section would benefit from the addition of more images.

 

Please remove this notice once you've added suitable images to the article.
The specific instructions are: Update start ticket image to 1.20.5

There are different ticket types, which come from various sources. If a ticket type defines a non-zero timeout, tickets of that type expire after that number of ticks. Each ticket type also has one or more flags that define how tickets of that type are handled.

The possible flags are:

• Persist – The ticket is persisted when the world is shut down, meaning when the world starts up again, the ticket is restored. This flag is set only for force-loading and portal tickets.
• Does load – Tickets with this flag load chunks. This flag is set for all ticket types.
• Does simulate – Tickets with this flag define an area where blocks and entities are updated.
• Should keep dimension active – Tickets with this flag prevent a dimension from stopping entity and block entity ticking altogether.
• Can expire if unloaded – Tickets with this flag, which is only the "unknown" ticket type, count down their remaining ticks even when their chunks are not fully loaded yet (or at all).

The following ticket types exist:

Player spawn

This type of ticket is created when a player (re)joins a world, at the location where the player will enter the world. It has a timeout of 1 second, but is refreshed while the (re)spawn area for the player is prepared. Tickets of this type are created at level 30 with radius 3 and only load chunks. The main purpose of this ticket type is to have the player spawn in a fully-generated chunk.

Spawn search

This type of ticket is created when a player's (re)spawn location needs to be determined, whether it's the player's first spawn in the world, or the player is respawning after dying or returning from the end, whether the player has a valid respawn point or uses the world spawn position. It has a timeout of 1 game tick. Tickets of this type are created at level 33 with a radius of 0 and only load chunks.

Dragon

This type of ticket is created and maintained by the Ender Dragon fight logic, for as long as any players can see the dragon's boss bar. When the ticket exists, it is positioned at chunk coordinates 0,0 in the end, has load level 24 with a radius of 9, has no timeout, and both loads and simulates chunks. It does not necessarily keep the end dimension active, though.

Player loading

Tickets of this type define the area players load around themselves. They are created at level 31, have no timeout, and only load chunks at level 31.

Player simulation

This type of ticket defines the area around a player where entity and block entity updates are actually processed. Tickets of this type are created at a level corresponding to an appropriate radius for the configured simulation distance. They have no timeout, and not just load and simulate chunks, but are also responsible for keeping the player's dimension active.

Forced

This type of ticket is created by the /forceload command. Tickets of this type have no timeout, are persisted, load and simulate chunks, and keep the dimension active. They are created individually at load level 31 for each chunk specified in the command.

Portal

This type of ticket is created whenever any entity (e.g. items, projectiles, mobs, or even a player) is teleported via a nether portal, end portal, or end gateway. The ticket is placed at the block position the entity was teleported to, which is not necessarily the same as the corresponding "exit side" of the portal or gateway that teleported the entity. The ticket has a timeout of 15 seconds, is persisted, loads and simulates chunks, and keeps the target dimension active. Portal tickets are created at level 30 with a radius of 3.

Ender pearl

This type of ticket is associated with a thrown ender pearl in the world. Tickets of this type have a timeout of 2 seconds, but are updated by the ender pearl whenever the timeout is about to run out or the ender pearl moved to a new chunk, for as long as the ender pearl exists. Note that if an ender pearl is moved into a lazy chunk through other means than its own movement (e.g. via a piston push), the pearl does not get an opportunity to update its ticket accordingly. Ender pearl tickets load and simulate chunks, and keep their dimension active. They are not persisted, but instead are tracked for each player and get restored when the player owning the ender pearl rejoins the world.

Unknown

When the game needs to immediately use the data of a chunk, but the chunk has not yet been created or generated to the required step, the game automatically gives a ticket named "unknown" to the chunk. Unknown tickets are inherently temporary and expire during the chunk source tick phase even if the chunk has not been fully loaded by then. They only load chunks and have a timeout of 1 game tick.

Limitations

Ticking

Though chunk loading tickets allow game features to occur relative to ticket type, some processes are subject to further restrictions.

Chunk loading caused by a player ticket allows entities to be ticked only if the chunk is in a square around the chunk which has the player ticket, as defined by the formulas described below. Entity despawning is not affected by this.

In singleplayer, "Simulation Distance" in options decides the side length of the square. It follows the formula ${\displaystyle l=min(2s+1,63)}$, where s is the selected simulation distance, and l is the side length (in chunks) of the square.

In multiplayer, "simulation-distance" configured in server.properties decides the side length of the square. It also follows the same formula ${\displaystyle l=min(2s+1,63)}$ where s is the configured "simulation-distance" and l is the side length of the square region.

Chunk loading caused by a player ticket allows block entities to be ticked and scheduled tick and chunk tick (without mob spawning) to be processed only if the chunk is in the aforementioned square region along with a one-chunk-thick square frame surrounding this region. That is, a square region with side length of ${\displaystyle l=min(2s+3,65)}$.

For example,

• With a simulation distance of 5 and a render distance of 10, entities move normally within a 11×11 chunk column around the player chunk. One more chunk out, within a one-chunk-thick square frame surrounding this region, redstone and command blocks still run, fluids flow, and crops grow. Zombies stop despawning naturally beyond 21×21 chunks.
• With a simulation distance of 5 and a render distance of 5, entities move normally within a 11×11 chunk column around the player chunk. One more chunk out, within a one-chunk-thick square frame surrounding this region, redstone and command blocks still run and fluids still flow, but crops stop growing. Zombies won't despawn because they are unloaded before being 128 blocks away from the player.
• With a simulation distance of 5 and a render distance of 2, entities move normally within a 5×5 chunk column around the player chunk. One more chunk out, within a one-chunk-thick square frame surrounding this region, redstone and command blocks still run and fluids still flow, but crops stop growing. Zombies won't despawn.

Technically, the above game aspects are controlled by another different ticket system named ticking ticket.

Idle timeout

Each dimension has its own idle timeout. It increases by 1 every game tick, while the game is not in /tick freeze mode. If there are chunk loading tickets in the dimension that keep the dimension active (i.e. any player, force-loaded chunks, active portal tickets, or ender pearls) or an entity enters the dimension via portal travel, the timeout is reset to 0.

If the timeout reaches 300 game ticks, the dimension stops processing certain actions. These include entity and block entity ticking, ender dragon fight, and global entities (lightning).

Others

Some game aspects don't always get processed in loading chunks because there may be other conditions for their progress, which includes the following:

• Chunk tick (including mob spawning)
  • Only chunks with centers within 128 blocks of a player are ticked on every game tick. See also Tick.
• Entities
  • Hostile mobs instantly despawn if they spawn more than 128 blocks from all players.
    • This includes zombified piglins at Nether portals and witches in witch huts.
  • Passive mobs do not spawn naturally outside a 240 block X 240 block area around a player.
    • The passive mob spawn cap is limited by the number of friendly mobs loaded into memory.
  • See also Mob spawn.

Exceptions

Events in a chunk may affect blocks in outside chunks. If the outside chunk is inactive, the effects are suspended in most cases. Specifically,

• Block changing on the edge of a block ticking chunk can spread updates to blocks outside the block ticking chunk and make them respond appropriately. The update may be propagated block by block until outside the border chunks, at which time it creates an unknown ticket to continue propagation.
• Block in a chunk with a 33 level can request a scheduled tick, but it does not get processed until the chunk gets a load level of 32 or below.
• Flowing water or lava can spread to the first adjacent block outside a block ticking chunk, but the flow becomes suspended there until the border chunk has a greater load level.
• Fire can spread to the first adjacent flammable block outside the block ticking chunk. Like water and lava, it becomes suspended there. It cannot spread further until the outside chunk gets a level of 32 or below.
• Grass and mycelium can spread to the first adjacent block outside an entity ticking chunk.
• Pumpkin and melon stem growing on the edge of an entity ticking chunk can place their fruits on an adjacent block outside the entity ticking chunk.
• An entity (mob, minecart, arrow, etc.) that attempts to move into a block ticking chunk from an entity ticking chunk becomes suspended as soon as it leaves the entity ticking chunk. When the block ticking chunk gets a greater level, the entity resumes moving.
• Exploding TNT in entity ticking chunks can damage or destroy blocks in a non-entity-ticking chunk.

Bedrock Edition chunk loading

All game aspects are active in loading chunks, including chunks within a player's simulation distance and chunks loaded by Commands/tickingarea. Unloaded chunks are unprocessed by the game and do not process any of the game aspects.

Player loaded chunks

Chunks are loaded around the player in a circle with a taxicab distance radius equal to one plus the simulation distance, except for the edges in cardinal directions, where the radius is equal to the simulation distance (see image).

If your simulation distance is set to 4, chunks around the player will be loaded in a taxicab "circle" with a radius of 5 centered on the chunk occupied by the player, but the north, east, south, and west edges will be cut off and have a taxicab radius of 4.

Loaded chunks can also be created with the /tickingarea command.

Limit

• Entities
  • Mob spawning is evaluated for every chunk within a 6 chunk cylindrical radius of the player that is loaded.

Exception

Events in a ticking area may affect blocks in outside chunks. If the outside chunk is inactive, the effects are suspended in most cases. Specifically,

• Block changing on the edge of a ticking area can spread updates to blocks outside the ticking area and respond appropriately.
• Flowing water or lava can spread to the first adjacent block in an outside chunk, but the flow becomes suspended there until the outside chunk becomes active.
• Fire can spread to the first adjacent flammable block outside the ticking area. Like water and lava, it becomes suspended there; although visible, its animation does not run, and it cannot spread further until the outside chunk becomes active.
• Grass and mycelium can spread to the first adjacent block in an outside chunk, but the affected block does not actually change its appearance until its chunk becomes active; it then changes instantly. Grass and mycelium cannot spread beyond the first such block, nor from such a block into the ticking area until the outside chunk becomes active.
• Pumpkin and melon stem growing on the edge of a ticking area can place their fruits on an adjacent block in an outside chunk.
• An entity (mob, minecart, arrow, etc.) that attempts to move into an outside chunk becomes suspended as soon as it leaves the ticking area. It remains visible but motionless. When the outside block becomes active, the entity resumes moving.
• Exploding TNT can damage or destroy blocks in an inactive chunk, and unlike other events, its effects are not limited to adjacent blocks. However, secondary effects in the outside chunk are suspended until the chunk becomes active. For instance, if an explosion destroys a block that supported sand or gravel, the sand or gravel does not fall immediately. The same thing happens with items that were attached to destroyed blocks, such as item frames and redstone torches; they do not drop until the chunk is activated.
• Primed TNT launched into an inactive chunk is suspended in mid-air within the first outside block it enters. It disappears until the outer chunk becomes active, at which time it resumes its flight and countdown.

Finding chunk edges

X and Z coordinates that are divisible by 16 represent the boundaries between chunks. EG: (96, -32) is a corner where four chunks meet. One of those chunks is between X coordinates 80 to 96 and Z coordinates -48 to -32. Another one is between X coordinates 96 to 112 and Z coordinates -32 to -16, and so on. When either X or Z crosses a multiple of 16, the player is moving across chunks.

Essentially, the player is in the top-left corner (north-western) of a chunk when both X and Z coordinates are divisible by 16.

Additionally, the player can know the chunk they are on by this formula:

The X of a chunk is floor(X coordinate / 16)
The Z of a chunk is floor(Z coordinate / 16)

Where floor is the largest previous integer. E.g. floor( 27.18 ) is 27, and floor( -3.14 ) is -4.

Also, the coordinates of a block within a chunk can be found by taking the coordinate mod 16.

For example, if the X coordinate of a player is 27, Z coordinate is −15, that player is on chunk (Floor(27/16), Floor(−15/16)), or chunk (1, −1), and at (27 mod 16, −15 mod 16), or (11, 1) within the chunk.

In Java Edition, the key F3 + G can be used to display chunk boundaries. Alternately, pressing the "F3" button opens the Debug screen that shows the player's X, Y, and Z coordinates, in addition to the "chunk" variable. These coordinates change as the player moves around. The player can know the chunk they are in by the variable "chunk".

In Bedrock Edition, when toggling fancy graphics, the world renders again, loading only the chunk the player is in for a split second, briefly showing the chunk boundaries. When the player changes the render distance rapidly, chunk barriers appear as a blue line. Also, if in mid-air and bridging with full blocks, the next block placed fades into view when a chunk border is intersected, showing the chunk border. This is sometimes unreliable, and it happens only on chunk borders. This does not happen underground or when the block placed is close to more than one block.

Slime chunks

Each chunk has a ¹⁄₁₀ chance of generating as a slime chunk, a chunk that slimes are able to spawn in below Y=40 and regardless of light level. These chunks are otherwise identical to normal chunks.

In Java Edition, whether a chunk at a particular set of coordinates becomes a slime chunk is determined by the world's seed. In Bedrock Edition, however, they are generated at the same coordinates in every world.

History

This section is missing information about: Bedrock Edition history

 

Please expand the section to include this information. Further details may exist on the talk page.

Java Edition

Legacy Console Edition

Issues

Issues relating to "Chunk" are maintained on the bug tracker. Issues should be reported and viewed there.

Trivia

• If a player stands in a chunk that has not generated yet, the world immediately becomes invisible until they are in a valid chunk. This does not happen if the Y coordinates are beyond the chunk boundaries.
• In Bedrock Edition, if one of the sixteen 16×16×16 sections of a chunk doesn't have any blocks in it, placing a block there shows the same animation as a chunk loading. This bug makes the block that the player placed to turn to the same color of the sky in the direction the player is facing for about 1 second and starts fading away into the normal block texture. If the time is sunrise or sunset and the player places a block there, it actually changes colors constantly for 1 second if the player keeps bobbing their head up and down. The block also makes blocks behind it appear invisible.

See also

• Chunk format
• Frame rate
• Altitude

References

Navigation