tryashtar

I cannot reproduce this. The second command properly made the bee attack me when substituting my UUID.

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:

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.

Java translations are done by the community on crowdin, so you can suggest a change there

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.

I cannot reproduce this.

Which issues are you referring to that affect 1.16.4 - 1.19.4?

Which security vulnerabilities are present in these versions?

By definition no old version can receive updates, since an update is a new version.

I was looking into this, and I think it might be caused by GLFW not finding the key names. I’d be curious to see your options.txt and maybe an F3+C crash report for the LWJGL version.

Reproduction on particular chests on seeds will be affected by MCPE-161133

Please include steps to reproduce this in a vanilla environment, and a description of how it affects the game.

Confirmed. This is caused by the item/amethyst_bud model overriding the fixed display of its parent item/generated in order to move it up slightly. The 180-degree rotation from item/generated is not included and so is overridden to 0.

This also causes amethyst buds and clusters to be mirrored when equipped in the head slot. No other items I found appeared to be affected in a similar way.

I believe this duplicates MC-143716

Nicely spotted. Would you please consider creating separate reports for these separate issues?

The behavior when pressing escape on the second screen changed from “return to the previous screen” to “respawn.” This change took place in 1.13-pre6 and is, to my understanding, what this report is describing.

If that change was intended, then I think this report is WAI, and a fix for the incidental issue of bypassing the delay timer was indeed made successfully in 25w36a. But it’s not clear at this time whether the behavior change was intended.

I cannot reproduce this

I can't reproduce this. It takes some time and gossip before golems become hostile, but it worked the same for me with a sword or spear

Nope, the NBT text component change fixed the crash

Please provide a single simple command that works differently in 1.21.10 compared to 1.21.9