Captain_S0L0
- Captain_S0L0
- JIRAUSER524600
- Europe/Stockholm
- Yes
- No
MC-242343![[Mojang] Gegy](../../../data/avatars/users/10122.svg){kind=small}
![[Mojang] SHugoh](../../../data/avatars/users/18947.svg){kind=small}
Added Attachments:
Added Attachments:
Added Attachments:
Steps to reproduce
- Create a new world with the experimental feature Bundles in Creative Mode.
- Open the inventory and get one bundle.
- Insert some items in the bundle and watch the tooltip.
It does not show the inserted items, but shows its number. This worked correctly in 23w14a.
Code analysis
A code analysis by Captain_S0L0 can be found in this comment.
Do note that experimental settings must be enabled on servers by modifying the server.properties to contain this line:
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.
Relates to
MC-260157.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.
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.
(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:
Notice something off about it? It calls the exact same thing twice!
Now take a ponder at the interfaces available via the TooltipComponent interface.
Oops, looks like drawItems() was forgotten to be called
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.
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.
I have also encountered this issue. This also occurs for the non-operator tab creative paintings.
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.
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).
This issue is NOT fixed in 24w10a, as while the tag is converted, it instead converts to
, which does not correctly apply the honey level when placed again (defaults to 0).
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:
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.
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