mojira.dev
MC-305482

/fillbiome is unreliable and difficult to control, often ignoring paramaters and affecting volumes that are a significant distance outside of the specified parameters

Steps to Reproduce:  

  1. For exact replication, create a Superflat world on the seed -3180699035942730568

  2. Run this command: /fill -5 -60 -16 -5 -53 0 minecraft:oak_leaves[persistent=true]

  3. Go over to the leaf wall and run this command: /fillbiome -5 -60 -12 -5 -59 -7 minecraft:river

Observed Results:  

Two separate and unique volumes of blocks are changed to the specified biome, one section mostly within the selected volume (as expected from the commands definition) and another section entirely outside of the specified parameters and completely detached from the section within the parameters.

Expected Results:  

Just the patch within the selected parameters is changed, not anywhere so drastically outside of and detached from the paramaters' volume.

A potential workaround for this could be to rework the fillbiome command to exactly match the parameters, making it much easier for users to precisely control where they want to be each biome.

(The vibrant colours of the leaves in the attached video are solely to help make the biome difference more visible, this problem still occurs without the datapack to change biome colours.)

Attachments

Comments 3

From the 22w46a changelog:

fillbiome
Changes biome entries for an area. Note that biomes are not stored per-block, so affected positions may not match input precisely.

@tryashtar

The description implies that the intended function isn’t to change two separate unrelated areas. Half of what is shown is the intended functionality (as inconvenient as it may be), and the other half of what I show in the video does not fit the description provided.

The bug isn’t the lack of precision (as I described understanding to be the intention within the “Observed Results”), the bug is the fabrication of parameters letting the command act completely independent and change an entirely separate and non-touching area in addition to the correct and intended area.

fillbiome is similar to forceload in that it accepts block coordinates as input, but only actually operates on the world at a coarser scale. For forceload, that scale is chunks. For fillbiome, the scale is “quarts” – 4x4x4 block sections. Each chunk is 4 quarts wide in both directions.

Here is the grid of quarts in your repro world:

2026-01-07_15.30.47.png

You’ll notice that between your two signs, there are exactly two quarts. That’s why the command says “2 biome entries set.”

However, biomes are “fuzzed” to make the edges look more natural, making individual blocks sample their biome from up to a few blocks away from the quart in which they reside. It just so happens that in your test, most of the blocks near the second sign happen to sample from the adjacent quart (+1X, just behind the leaf wall). They appear unaffected, since that quart wasn’t in your command’s bounds. Many of the blocks past the second sign happen to sample from the sign’s quart (-1Z). They appear affected, since that quart was in your command’s bounds.

The area is not “completely separate and non-touching.” It’s within 2 blocks of the affected region, which is completely expected according to the description of the command as “not matching input precisely.”

I hope this explanation was satisfactory.

Entityyy

(Unassigned)

Confirmed

(Unassigned)

1.21.11

Retrieved