Captain_S0L0

Affects 25w33a

As it somehow has not been mentioned here yet, this bug leads to a rather nasty side effect that malicious servers can exploit. Servers can send a sign edit GUI that contains translation or keybind formatting, which the client will resolve and send back to the server in plain text. This can be used to get the player's language, keybindings, and detect mods that include custom keybinds or translation texts.

This issue can also be exploited within the anvil as well by sending an item with such a formatting for a name, which the client will resolve and update within the anvil output slot.

Worst of all is that the server can also immediately close such a GUI, such that the client will never see it appear visually.

Here is a (now unmaintained) mod that seeks to fix this issue: https://github.com/JustAlittleWolf/ModDetectionPreventer

Can confirm for 1.20.6 and 1.21 Pre-Release 2.

I've figured out why this occurs, and wish to add exact reproduction instructions so this super annoying bug can get fixed. The root cause is that the nether and end do not have their rain state correctly initialized upon world load.

Reproduction steps:

1. Create a world. Make sure it is NOT raining, then save and quit.

2. Reload the world. Bees will leave their hives in the nether and end.

3. Set the weather to rain, and save and quit.

4. Reload the world. Bees will no longer leave their hives in the nether and end.

Code analysis (using Mojang mappings):

When a world is first loaded, a ServerLevelData object is loaded from level.dat to provide various world information, such as time or weather. This information is used in loading all dimensions. Next, in the <init> function of ServerLevel, prepareWeather() is called. This function checks the provided ServerLevelData object and if it is raining, sets rainLevel to 1.0f (otherwise it defaults to 0.0f). Now why is this important?

rainLevel is only ever updated in one other function - advanceWeatherCycle() in ServerLevel, and if the world's dimension returns false for hasSkyLight(), then that method will never change rainLevel, causing it to remain at the value it was initialized to until the world is unloaded and saved to disk.

BehiveBlockEntity calls releaseOccupant() to attempt to release its bees, which will return false if the release reason is not BeeReleaseStatus.EMERGENCY and either isNight() or isRaining() returns true. isNight() will always return false for dimensions with a fixed time (which the nether and end are), and isRaining() returns whether the world's rainLevel is greater than 0.2f.

Thus if the world was saved while raining, upon reloading bees will never be able to leave their hives until the world is saved again when it is not raining.

This issue is NOT fixed in 24w10a, as while the tag is converted, it instead converts to

"minecraft:block_state": {honey_level:"true"}

, which does not correctly apply the honey level when placed again (defaults to 0).

Well that's a disappointment. I remember that external editing used to be at least somewhat "supported" when it comes to bugs (e.g. MC-4433), and not having access to these values causes the loss of quite some custom map and gameplay potential.

In either case, if there's no point in storing the data as it's regenerated on login anyways, then it's wasting disk space (abiet little).

Can confirm.

It seems that if a comparator is placed on the opposite face from the dispenser that it does receive an update, but the other sides do not. I've added a screenshot to show this.

I have also encountered this issue. This also occurs for the non-operator tab creative paintings.

This will also occur with bundles as well as shulker boxes.
Notably, this can also be triggered when overstacked items are present within each.

I've also attached an example world so the effects can be seen when updating.

Likely a result of using modified server software with the plugin WorldEdit, which provides functionality with compasses to operators that teleports the player to the nearest empty space through walls upon right clicking.

(note: all class names are from yarn mappings, so keep that in mind)

This is a result of the new modifications to the DrawableHelper class. See the code utilized for rendering an item's tooltip:

private void method_51435(TextRenderer textRenderer, List<TooltipComponent> list, int i, int j, TooltipPositioner tooltipPositioner) {
    if (!list.isEmpty()) {
        
        //lots of boilerplate setup that is irrelevant to the bug

        for(t = 0; t < list.size(); ++t) {
            tooltipComponent2 = (TooltipComponent)list.get(t);
            tooltipComponent2.drawText(textRenderer, p, s, this.field_44657.peek().getPositionMatrix(), this.field_44658);
            s += tooltipComponent2.getHeight() + (t == 0 ? 2 : 0);
        }

        s = q;

        for(t = 0; t < list.size(); ++t) {
            tooltipComponent2 = (TooltipComponent)list.get(t);
            tooltipComponent2.drawText(textRenderer, p, s, this.field_44657.peek().getPositionMatrix(), this.field_44658);
            s += tooltipComponent2.getHeight() + (t == 0 ? 2 : 0);
        }

        this.field_44657.pop();
    }
}

Notice something off about it? It calls the exact same thing twice!

Now take a ponder at the interfaces available via the TooltipComponent interface.

int getHeight();

int getWidth(TextRenderer textRenderer);

default void drawText(TextRenderer textRenderer, int x, int y, Matrix4f matrix, VertexConsumerProvider.Immediate vertexConsumers) {
}

default void drawItems(TextRenderer textRenderer, int x, int y, DrawableHelper drawableHelper) {
}

Oops, looks like drawItems() was forgotten to be called 😞

Updating between snapshots is still updating.

The issue is not just with updating old worlds, which I do understand is not officially supported. It is also an issue with dedicated servers, running 23w07a, the most recent snapshot version as of this comment, generating a completely new world with snapshot features enabled, fails to generate the new Cherry Grove biome.

It is not just for worlds that have been updated, though. Worlds generated with experimental settings enabled in the server.properties on a fresh 23w07a dedicated server fail to enable the new biomes.

Relates to MC-260157.

Do note that experimental settings must be enabled on servers by modifying the server.properties to contain this line:

initial-enabled-packs=bundle,update_1_20,vanilla

However, this line being missing is not the root cause of the issue, just a helpful note for those attempting to reproduce. The underlying cause is that worlds either updated from previous versions (i.e. 23w06a) with experimental settings enabled, or generated from a dedicated server with the aforementioned line in server.properties, will set the biome_source of the overworld generator in level.dat to "minecraft:overworld". In singleplayer 23w07a, creating a new world with experimental features enabled will instead set this value to "minecraft:overworld_update_1_20", which is the generator that allows the new Cherry Grove to generate.

I have also attatched images of two example level.dat files, as provided by the program NBTExplorer.