kanokarob
- kanokarob
- JIRAUSER531953
- Europe/Stockholm
- Yes
- No
MC-196201![[Mojang] Georgii Gavrichev](../../../data/avatars/users/22428.png){kind=small}
![[Mojang] Billy Sjöberg](../../../data/avatars/users/42806.png){kind=small}
![[Mojang] Bartosz Bok](../../../data/avatars/users/10122.svg){kind=small}
When two entities that have the same size hitbox occupy the same space, attempting to right click those entities where they overlap doesn't always prefer the same entity's hitbox over the other.
In the example this was noticed and is demonstrated in, an Enderman and a Villager have the same width and length hitbox. (The villager is invisible, viewed in spectator mode in the attachment, so while the height is different of course, this doesn't affect the bug. For general interactivity, they are the same size. Both have NoAI:1 and therefore cannot move or be moved without commands.) When the player attempts to right click the "hybrid" entity in the parts of their hitbox which they overlap, they are given the villager's trading menu.
Sometimes, however, especially after the player has left the End and then returned, the opposite will be true-interacting with the hybrid does not bring up the trade menu, presumably because now the Enderman's hitbox is taking precedence. This can be reversed yet again by changing dimensions, exiting and re-entering the world through the menu, etc., however never in any predictable way. Further, this has yet to be recreated for the same setup of entities in the Overworld-leaving and then re-entering the dimension doesn't seem to affect the preferred hitbox there, although this may be by chance than by function.
Obviously this kind of arrangement of entities isn't a vanilla survival occurrence, however it is a useful mechanism for Adventure Maps and for Data Packs to use that should be possible in vanilla. The map/pack creator should be able to count on this type of entity arrangement working the same way, every time-to know which of the entities the game is going to give hitbox precedence to, even if that means removing the ability for the villager's hitbox to take priority over the Enderman's, although that would be the main reason to repair this bug.
When two entities that have the same size hitbox occupy the same space, attempting to right click those entities where they overlap doesn't always prefer the same entity's hitbox over the other.
In the example this was noticed and is demonstrated in, an Enderman and a Villager have the same width and length hitbox. (The villager is invisible, viewed in spectator mode in the attachment, so while the height is different of course, this doesn't affect the bug. For general interactivity, they are the same size. Both have NoAI:1 and therefore cannot move or be moved without commands.) When the player attempts to right click the "hybrid" entity in the parts of their hitbox which they overlap, they are given the villager's trading menu.
Sometimes, however, especially after the player has left the End and then returned, the opposite will be true-interacting with the hybrid does not bring up the trade menu, presumably because now the Enderman's hitbox is taking precedence. This can be reversed yet again by changing dimensions, exiting and re-entering the world through the menu, etc., however never in any predictable way
. Further, this has yet to be recreated for the same setup of entities in the Overworld-leaving and then re-entering the dimension doesn't seem to affect the preferred hitbox there, although this may be by chance than by function.Obviously this kind of arrangement of entities isn't a vanilla survival occurrence, however it is a useful mechanism for Adventure Maps and for Data Packs to use that should be possible in vanilla. The map/pack creator should be able to count on this type of entity arrangement working the same way, every time-to know which of the entities the game is going to give hitbox precedence to, even if that means removing the ability for the villager's hitbox to take priority over the Enderman's, although that would be the main reason to repair this bug.
When two entities that have the same size hitbox occupy the same space, attempting to right click those entities where they overlap doesn't always prefer the same entity's hitbox over the other.
In the example this was noticed and is demonstrated in, an Enderman and a Villager have the same width and length hitbox. (The villager is invisible, viewed in spectator mode in the attachment, so while the height is different of course, this doesn't affect the bug. For general interactivity, they are the same size. Both have NoAI:1 and therefore cannot move or be moved without commands.) When the player attempts to right click the "hybrid" entity in the parts of their hitbox which they overlap, they are given the villager's trading menu.
Sometimes, however, especially after the player has left the End and then returned, the opposite will be true-
interacting with the hybrid does not bring up the trade menu, presumably because now the Enderman's hitbox is taking precedence. This can be reversed yet again by changing dimensions, exiting and re-entering the world through the menu, etc., however never in any predictable way. Further, this has yet to be recreated for the same setup of entities in the Overworld-leaving and then re-entering the dimension doesn't seem to affect the preferred hitbox there, although this may be by chance than by function.Obviously this kind of arrangement of entities isn't a vanilla survival occurrence, however it is a useful mechanism for Adventure Maps and for Data Packs to use that should be possible in vanilla. The map/pack creator should be able to count on this type of entity arrangement working the same way, every time-to know which of the entities the game is going to give hitbox precedence to, even if that means removing the ability for the villager's hitbox to take priority over the Enderman's, although that would be the main reason to repair this bug.
When two entities that have the same size hitbox occupy the same space, attempting to right click those entities where they overlap doesn't always prefer the same entity's hitbox over the other.
In the example this was noticed and is demonstrated in, an Enderman and a Villager have the same width and length hitbox. (The villager is invisible, viewed in spectator mode in the attachment, so while the height is different of course, this doesn't affect the bug. For general interactivity, they are the same size. Both have NoAI:1 and therefore cannot move or be moved without commands.) When the player attempts to right click the "hybrid" entity in the parts of their hitbox which they overlap, they are given the villager's trading menu.
Sometimes, however, especially after the player has left the End and then returned, the opposite will be true-
interacting with the hybrid does not bring up the trade menu, presumably because now the Enderman's hitbox is taking precedence. This can be reversed yet again by changing dimensions, exiting and re-entering the world through the menu, etc., however never in any predictable way. Further, this has yet to be recreated for the same setup of entities in the Overworld-leaving and then re-entering the dimension doesn't seem to affect the preferred hitbox there, although this may be by chance than by function.Obviously this kind of arrangement of entities isn't a vanilla survival occurrence, however it is a useful mechanism for Adventure Maps and for Data Packs to use that should be possible in vanilla. The map/pack creator should be able to count on this type of entity arrangement working the same way, every time-to know which of the entities the game is going to give hitbox precedence to, even if that means removing the ability for the villager's hitbox to take priority over the Enderman's, although that would be the main reason to repair this bug.
When two entities that have the same size hitbox occupy the same space, attempting to right click those entities where they overlap doesn't always prefer the same entity's hitbox over the other.
In the example this was noticed and is demonstrated in, an Enderman and a Villager have the same width and length hitbox. (The villager is invisible, viewed in spectator mode in the attachment, so while the height is different of course, this doesn't affect the bug. For general interactivity, they are the same size. Both have NoAI:1 and therefore cannot move or be moved without commands.) When the player attempts to right click the "hybrid" entity in the parts of their hitbox which they overlap, they are given the villager's trading menu.
Sometimes, however, especially after the player has left the End and then returned, the opposite will be true-interacting with the hybrid does not bring up the trade menu, presumably because now the Enderman's hitbox is taking precedence. This can be reversed yet again by changing dimensions, exiting and re-entering the world through the menu, etc., however never in any predictable way. Further, this has yet to be recreated for the same setup of entities in the Overworld-leaving and then re-entering the dimension doesn't seem to affect the preferred hitbox there, although this may be by chance than by function.
Obviously this kind of arrangement of entities isn't a vanilla survival occurrence, however it is a useful mechanism for Adventure Maps and for Data Packs to use that should be possible in vanilla. The map/pack creator should be able to count on this type of entity arrangement working the same way, every time-to know which of the entities the game is going to give hitbox precedence to, even if that means removing the ability for the villager's hitbox to take priority over the Enderman's, although that would be the main reason to repair this bug.
When two entities that have the same size hitbox occupy the same space, attempting to right click those entities where they overlap doesn't always prefer the same entity's hitbox over the other.
In the example this was noticed and is demonstrated in, an Enderman and a Villager have the same width and length hitbox. (The villager is invisible, viewed in spectator mode in the attachment, so while the height is different of course, this doesn't affect the bug. For general interactivity, they are the same size. Both have NoAI:1 and therefore cannot move or be moved without commands.) When the player attempts to right click the "hybrid" entity in the parts of their hitbox which they overlap, they are given the villager's trading menu.
Sometimes, however, especially after the player has left the End and then returned, the opposite will be true
-interacting with the hybrid does not bring up the trade menu, presumably because now the Enderman's hitbox is taking precedence. This can be reversed yet again by changing dimensions, exiting and re-entering the world through the menu, etc., however never in any predictable way. Further, this has yet to be recreated for the same setup of entities in the Overworld-leaving and then re-entering the dimension doesn't seem to affect the preferred hitbox there, although this may be by chance than by function.Obviously this kind of arrangement of entities isn't a vanilla survival occurrence, however it is a useful mechanism for Adventure Maps and for Data Packs to use that should be possible in vanilla. The map/pack creator should be able to count on this type of entity arrangement working the same way, every time
-to know which of the entities the game is going to give hitbox precedence to, even if that means removing the ability for the villager's hitbox to take priority over the Enderman's, although that would be the main reason to repair this bug.When two entities that have the same size hitbox occupy the same space, attempting to right click those entities where they overlap doesn't always prefer the same entity's hitbox over the other.
In the example this was noticed and is demonstrated in, an Enderman and a Villager have the same width and length hitbox. (The villager is invisible, viewed in spectator mode in the attachment, so while the height is different of course, this doesn't affect the bug. For general interactivity, they are the same size. Both have NoAI:1 and therefore cannot move or be moved without commands.) When the player attempts to right click the "hybrid" entity in the parts of their hitbox which they overlap, they are given the villager's trading menu.
Sometimes, however, especially after the player has left the End and then returned, the opposite will be true - interacting with the hybrid does not bring up the trade menu, presumably because now the Enderman's hitbox is taking precedence. This can be reversed yet again by changing dimensions, exiting and re-entering the world through the menu, etc., however never in any predictable way. Further, this has yet to be recreated for the same setup of entities in the Overworld - leaving and then re-entering the dimension doesn't seem to affect the preferred hitbox there, although this may be by chance than by function.
Obviously this kind of arrangement of entities isn't a vanilla survival occurrence, however it is a useful mechanism for Adventure Maps and for Data Packs to use that should be possible in vanilla. The map/pack creator should be able to count on this type of entity arrangement working the same way, every time - to know which of the entities the game is going to give hitbox precedence to, even if that means removing the ability for the villager's hitbox to take priority over the Enderman's, although that would be the main reason to repair this bug.
netherrack_replace_blobs with water as target crashes the game
In custom world generation, using netherrack_replace_blobs features to replace water (or possibly any block that has key properties) causes the game to crash when affected chunks are loaded. netherrack_replace_blobs with other blocks as targets do not exhibit this behavior. No syntax errors are reported by the game log when the world is loaded with the data pack.
Recreation steps:
- Download the attached data pack and create a new world with it.
- Use /execute in nitdim:primordial_desert run tp ~ 120 ~
- Use /locatebiome nitdim:primordial_desert/canyon
- Either teleport to the destination, or for more controlled testing, slowly fly there in creative mode so you can see when the crash occurs as the chunks begin to load.
Feature is located in nitdim/worldgen/configured_features/primordial_desert/replacer_water
To demonstrate this doesn't occur otherwise, you can remove this feature from the canyon biome or change the target to another block, like stone, and delete the region files to regenerate those chunks.
Other netherrack_replace_blobs are used elsewhere in the pack using blocks that have no key properties as targets, most notably in the buried_ocean dimension. They cause no errors or crashes themselves, and this feature is an identical copy to those ones, except for the target/state.
In custom world generation, using netherrack_replace_blobs features to replace water (or possibly any block that has key properties) causes the game to crash when affected chunks are loaded. netherrack_replace_blobs with other blocks as targets do not exhibit this behavior. No syntax errors are reported by the game log when the world is loaded with the data pack.
Crash report: https://pastebin.com/m8hm0s0B
Recreation steps:
- Download the attached data pack and create a new world with it.
- Use /execute in nitdim:primordial_desert run tp ~ 120 ~
- Use /locatebiome nitdim:primordial_desert/canyon
- Either teleport to the destination, or for more controlled testing, slowly fly there in creative mode so you can see when the crash occurs as the chunks begin to load.
Feature is located in nitdim/worldgen/configured_features/primordial_desert/replacer_water
To demonstrate this doesn't occur otherwise, you can remove this feature from the canyon biome or change the target to another block, like stone, and delete the region files to regenerate those chunks.
Other netherrack_replace_blobs are used elsewhere in the pack using blocks that have no key properties as targets, most notably in the buried_ocean dimension. They cause no errors or crashes themselves, and this feature is an identical copy to those ones, except for the target/state.
nit-dimensions-canyon-error.zip
A change was made to the item_used_on_block advancement criteria in this snapshot(s) such that the criteria only triggers/grants if the action made a change to the block, in order to fix an inconsistency with using axes on Waxed Copper Doors and Trapdoors (
MC-266055). However, this change breaks previous functionality by no longer allowing the criteria to trigger when interacting with any block unless the use caused some action.This behavior was used previously by data pack authors to detect when players interacted with any number of blocks, and in particular, block entities – with or without items – and is not easily replicable without.
To recreate this behavior:
- Download the attached Data Pack and install it on a world in 1.20.4
- Place a Dropper, and then inside it, place 8 Dirt in the center, and 1 Wheat Seeds in each other slot.
- Close, then open the dropper. You should receive an advancement, signified by a chat message and sound. The advancement revokes, so you can repeat this.
- Close the game, then launch in 23w51b and load the same world.
- Open the dropper. You will not receive the advancement anymore, but it can still be granted with commands (/advancement grant @s only item
/open_dropper)This is an unannounced feature change that impacts many existing data packs.
A change was made to the item_used_on_block advancement criteria in this snapshot(s) such that the criteria only triggers/grants if the action made a change to the block, in order to fix an inconsistency with using axes on Waxed Copper Doors and Trapdoors (https://bugs.mojang.com/browse/MC-266055). However, this change breaks previous functionality by no longer allowing the criteria to trigger when interacting with any block unless the use caused some action.
This behavior was used previously by data pack authors to detect when players interacted with any number of blocks, and in particular, block entities – with or without items – and is not easily replicable without.
To recreate this behavior:
- Download the attached Data Pack and install it on a world in 1.20.4
- Place a Dropper, and then inside it, place 8 Dirt in the center, and 1 Wheat Seeds in each other slot.
- Close, then open the dropper. You should receive an advancement, signified by a chat message and sound. The advancement revokes, so you can repeat this.
- Close the game, then launch in 23w51b and load the same world.
- Open the dropper. You will not receive the advancement anymore, but it can still be granted with commands (/advancement grant @s only item:open_dropper)
This is an unannounced feature change that impacts many existing data packs.
Changes to item_used_on_block advancement cirteria breaks previous functionalityChanges to item_used_on_block advancement criteria breaks previous functionality
Non-existent entries inbiometags that are not required causes validation errorNon-existent entries in certain tags that are not required causes validation error
If a biome tag is included in a data pack, which includes an entry with required set to false, and that biome ID is not present in any data packs, the data pack fails to validate and the game tries to launch in Safe Mode. The output log produces this error:
[Render thread/ERROR]: Registry loading errors: > Errors in registry minecraft:root: >> Errors in element minecraft:worldgen/biome: java.lang.IllegalStateException: Unbound values in registry ResourceKey[minecraft:root / minecraft:worldgen/biome]: [test:test] at net.minecraft.core.MappedRegistry.net.minecraft.core.Registry freeze()(MappedRegistry.java:333) at net.minecraft.resources.RegistryDataLoader.void lambda$load$6(java.util.Map,net.minecraft.resources.RegistryDataLoader$Loader)(RegistryDataLoader.java:188) at java.base/java.lang.Iterable.forEach(Iterable.java:75) at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.resources.RegistryDataLoader$LoadingFunction,java.util.List,java.util.List)(RegistryDataLoader.java:185) at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.server.packs.resources.ResourceManager,java.util.List,java.util.List)(RegistryDataLoader.java:164) at net.minecraft.resources.RegistryDataLoader.void lambda$load$2(net.minecraft.server.packs.resources.ResourceManager,net.minecraft.resources.RegistryDataLoader$Loader,net.minecraft.resources.RegistryOps$RegistryInfoLookup)(RegistryDataLoader.java:164) at net.minecraft.server.WorldLoader.java.util.concurrent.CompletableFuture load(net.minecraft.server.WorldLoader$InitConfig,net.minecraft.server.WorldLoader$WorldDataSupplier,net.minecraft.server.WorldLoader$ResultFactory,java.util.concurrent.Executor,java.util.concurrent.Executor)(WorldLoader.java:41) at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void applyNewPackConfig(net.minecraft.server.packs.repository.PackRepository,net.minecraft.world.level.WorldDataConfiguration,java.util.function.Consumer)(CreateWorldScreen.java:574) at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void tryApplyNewDataPacks(net.minecraft.server.packs.repository.PackRepository,boolean,java.util.function.Consumer)(CreateWorldScreen.java:564) at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void lambda$openDataPackSelectionScreen$8(net.minecraft.server.packs.repository.PackRepository)(CreateWorldScreen.java:536) at net.minecraft.client.gui.screens.packs.PackSelectionModel.void commit()(PackSelectionModel.java:56) at net.minecraft.client.gui.screens.packs.PackSelectionScreen.void onClose()(PackSelectionScreen.java:94) at net.minecraft.client.gui.screens.packs.PackSelectionScreen.void lambda$init$1(net.minecraft.client.gui.components.Button)(PackSelectionScreen.java:124) at net.minecraft.client.gui.components.Button.void onPress()(Button.java:96) at net.minecraft.client.gui.components.AbstractButton.void onClick(double,double)(AbstractButton.java:43) at net.minecraft.client.gui.components.AbstractWidget.boolean mouseClicked(double,double,int)(AbstractWidget.java:141) at net.minecraft.client.gui.components.AbstractWidget.void updateWidgetNarration(net.minecraft.client.gui.narration.NarrationElementOutput)(AbstractWidget.java:141) at net.minecraft.client.gui.components.events.ContainerEventHandler.boolean mouseClicked(double,double,int)(ContainerEventHandler.java:38) at net.minecraft.client.gui.components.events.ContainerEventHandler.void setFocused(net.minecraft.client.gui.components.events.GuiEventListener)(ContainerEventHandler.java:38) at net.minecraft.client.MouseHandler.void lambda$onPress$0(boolean[],net.minecraft.client.gui.screens.Screen,double,double,int)(MouseHandler.java:111) at net.minecraft.client.gui.screens.Screen.void wrapScreenError(java.lang.Runnable,java.lang.String,java.lang.String)(Screen.java:429) at net.minecraft.client.MouseHandler.void onPress(long,int,int,int)(MouseHandler.java:111) at net.minecraft.client.MouseHandler.void lambda$setup$4(long,int,int,int)(MouseHandler.java:189) at net.minecraft.util.thread.BlockableEventLoop.void execute(java.lang.Runnable)(BlockableEventLoop.java:110) at net.minecraft.client.MouseHandler.void lambda$setup$5(long,int,int,int)(MouseHandler.java:189) at org.lwjgl.glfw.GLFWMouseButtonCallbackI.null callback(null)(GLFWMouseButtonCallbackI.java:43) at org.lwjgl.system.JNI.null invokeV(null)(JNI.java) at org.lwjgl.glfw.GLFW.null glfwWaitEventsTimeout(null)(GLFW.java:3509) at com.mojang.blaze3d.systems.RenderSystem.void limitDisplayFPS(int)(RenderSystem.java:178) at net.minecraft.client.Minecraft.void runTick(boolean)(Minecraft.java:1327) at net.minecraft.client.Minecraft.void run()(Minecraft.java:898) at net.minecraft.client.main.Main.void main(java.lang.String[])(Main.java:256) [Render thread/WARN]: Failed to validate datapack java.util.concurrent.CompletionException: net.minecraft.ReportedException: Registry Loading at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332) ~[?:?] at java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:674) ~[?:?] at java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:662) ~[?:?] at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2200) ~[?:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void applyNewPackConfig(net.minecraft.server.packs.repository.PackRepository,net.minecraft.world.level.WorldDataConfiguration,java.util.function.Consumer)(CreateWorldScreen.java:604) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void tryApplyNewDataPacks(net.minecraft.server.packs.repository.PackRepository,boolean,java.util.function.Consumer)(CreateWorldScreen.java:564) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void lambda$openDataPackSelectionScreen$8(net.minecraft.server.packs.repository.PackRepository)(CreateWorldScreen.java:536) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.packs.PackSelectionModel.void commit()(PackSelectionModel.java:56) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.packs.PackSelectionScreen.void onClose()(PackSelectionScreen.java:94) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.packs.PackSelectionScreen.void lambda$init$1(net.minecraft.client.gui.components.Button)(PackSelectionScreen.java:124) ~[24w34a.jar:?] at net.minecraft.client.gui.components.Button.void onPress()(Button.java:96) ~[24w34a.jar:?] at net.minecraft.client.gui.components.AbstractButton.void onClick(double,double)(AbstractButton.java:43) ~[24w34a.jar:?] at net.minecraft.client.gui.components.AbstractWidget.boolean mouseClicked(double,double,int)(AbstractWidget.java:141) ~[24w34a.jar:?] at net.minecraft.client.gui.components.AbstractWidget.void updateWidgetNarration(net.minecraft.client.gui.narration.NarrationElementOutput)(AbstractWidget.java:141) ~[24w34a.jar:?] at net.minecraft.client.gui.components.events.ContainerEventHandler.boolean mouseClicked(double,double,int)(ContainerEventHandler.java:38) ~[24w34a.jar:?] at net.minecraft.client.gui.components.events.ContainerEventHandler.void setFocused(net.minecraft.client.gui.components.events.GuiEventListener)(ContainerEventHandler.java:38) ~[24w34a.jar:?] at net.minecraft.client.MouseHandler.void lambda$onPress$0(boolean[],net.minecraft.client.gui.screens.Screen,double,double,int)(MouseHandler.java:111) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.Screen.void wrapScreenError(java.lang.Runnable,java.lang.String,java.lang.String)(Screen.java:429) ~[24w34a.jar:?] at net.minecraft.client.MouseHandler.void onPress(long,int,int,int)(MouseHandler.java:111) ~[24w34a.jar:?] at net.minecraft.client.MouseHandler.void lambda$setup$4(long,int,int,int)(MouseHandler.java:189) ~[24w34a.jar:?] at net.minecraft.util.thread.BlockableEventLoop.void execute(java.lang.Runnable)(BlockableEventLoop.java:110) ~[24w34a.jar:?] at net.minecraft.client.MouseHandler.void lambda$setup$5(long,int,int,int)(MouseHandler.java:189) ~[24w34a.jar:?] at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:43) [lwjgl-glfw-3.3.3.jar:build 5] at org.lwjgl.system.JNI.null invokeV(null)(JNI.java) ~[lwjgl-3.3.3.jar:build 5] at org.lwjgl.glfw.GLFW.glfwWaitEventsTimeout(GLFW.java:3509) [lwjgl-glfw-3.3.3.jar:build 5] at com.mojang.blaze3d.systems.RenderSystem.limitDisplayFPS(SourceFile:178) [24w34a.jar:?] at fil.c(SourceFile:1327) [24w34a.jar:?] at fil.f(SourceFile:898) [24w34a.jar:?] at net.minecraft.client.main.Main.main(SourceFile:256) [24w34a.jar:?] Caused by: net.minecraft.ReportedException: Registry Loading at net.minecraft.resources.RegistryDataLoader.net.minecraft.ReportedException createReportWithBriefInfo(java.util.Map)(RegistryDataLoader.java:267) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.ReportedException logErrors(java.util.Map)(RegistryDataLoader.java:232) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.resources.RegistryDataLoader$LoadingFunction,java.util.List,java.util.List)(RegistryDataLoader.java:199) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.server.packs.resources.ResourceManager,java.util.List,java.util.List)(RegistryDataLoader.java:164) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.void lambda$load$2(net.minecraft.server.packs.resources.ResourceManager,net.minecraft.resources.RegistryDataLoader$Loader,net.minecraft.resources.RegistryOps$RegistryInfoLookup)(RegistryDataLoader.java:164) ~[24w34a.jar:?] at net.minecraft.server.WorldLoader.java.util.concurrent.CompletableFuture load(net.minecraft.server.WorldLoader$InitConfig,net.minecraft.server.WorldLoader$WorldDataSupplier,net.minecraft.server.WorldLoader$ResultFactory,java.util.concurrent.Executor,java.util.concurrent.Executor)(WorldLoader.java:41) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void applyNewPackConfig(net.minecraft.server.packs.repository.PackRepository,net.minecraft.world.level.WorldDataConfiguration,java.util.function.Consumer)(CreateWorldScreen.java:574) ~[24w34a.jar:?] ... 22 more Caused by: java.lang.IllegalStateException: Failed to load registries due to errors at net.minecraft.resources.RegistryDataLoader.net.minecraft.ReportedException createReportWithBriefInfo(java.util.Map)(RegistryDataLoader.java:251) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.ReportedException logErrors(java.util.Map)(RegistryDataLoader.java:232) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.resources.RegistryDataLoader$LoadingFunction,java.util.List,java.util.List)(RegistryDataLoader.java:199) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.server.packs.resources.ResourceManager,java.util.List,java.util.List)(RegistryDataLoader.java:164) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.void lambda$load$2(net.minecraft.server.packs.resources.ResourceManager,net.minecraft.resources.RegistryDataLoader$Loader,net.minecraft.resources.RegistryOps$RegistryInfoLookup)(RegistryDataLoader.java:164) ~[24w34a.jar:?] at net.minecraft.server.WorldLoader.java.util.concurrent.CompletableFuture load(net.minecraft.server.WorldLoader$InitConfig,net.minecraft.server.WorldLoader$WorldDataSupplier,net.minecraft.server.WorldLoader$ResultFactory,java.util.concurrent.Executor,java.util.concurrent.Executor)(WorldLoader.java:41) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void applyNewPackConfig(net.minecraft.server.packs.repository.PackRepository,net.minecraft.world.level.WorldDataConfiguration,java.util.function.Consumer)(CreateWorldScreen.java:574) ~[24w34a.jar:?] ... 22 moreAnd then lists the
biomeIDs that were listed, but are missing.Expected behavior is that if these IDs are not present among any loaded data packs, because they are not required, the game will ignore them for these tags and validate without them.
Steps to recreate:
- Create a tag in <namespace>/tags/worldgen/biome
- Make this tag include at least one biome that does not exist, as an object with "required": false. For example, "test:test"
- Attempt to load the data pack in a world
- Observe that the game attempts to load the world in Safe Mode, and the output log has produced the above error.
- Perform the same test in 1.21.1 and note that the data pack validates as expected.
Example tag for convenience:
{ "values": [ "minecraft:plains", { "id": "test:test", "required": false } ] }
If a biome, structure, enchantment, or loot table tag is included in a data pack, which includes an entry with required set to false, and that biome/structure/enchantment/loot_table ID is not present in any data packs, the data pack fails to validate and the game tries to launch in Safe Mode. The output log produces this error (example with biome tag):
deobf_latest.log[Render thread/ERROR]: Registry loading errors: > Errors in registry minecraft:root: >> Errors in element minecraft:worldgen/biome: java.lang.IllegalStateException: Unbound values in registry ResourceKey[minecraft:root / minecraft:worldgen/biome]: [test:test] at net.minecraft.core.MappedRegistry.net.minecraft.core.Registry freeze()(MappedRegistry.java:333) at net.minecraft.resources.RegistryDataLoader.void lambda$load$6(java.util.Map,net.minecraft.resources.RegistryDataLoader$Loader)(RegistryDataLoader.java:188) at java.base/java.lang.Iterable.forEach(Iterable.java:75) at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.resources.RegistryDataLoader$LoadingFunction,java.util.List,java.util.List)(RegistryDataLoader.java:185) at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.server.packs.resources.ResourceManager,java.util.List,java.util.List)(RegistryDataLoader.java:164) at net.minecraft.resources.RegistryDataLoader.void lambda$load$2(net.minecraft.server.packs.resources.ResourceManager,net.minecraft.resources.RegistryDataLoader$Loader,net.minecraft.resources.RegistryOps$RegistryInfoLookup)(RegistryDataLoader.java:164) at net.minecraft.server.WorldLoader.java.util.concurrent.CompletableFuture load(net.minecraft.server.WorldLoader$InitConfig,net.minecraft.server.WorldLoader$WorldDataSupplier,net.minecraft.server.WorldLoader$ResultFactory,java.util.concurrent.Executor,java.util.concurrent.Executor)(WorldLoader.java:41) at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void applyNewPackConfig(net.minecraft.server.packs.repository.PackRepository,net.minecraft.world.level.WorldDataConfiguration,java.util.function.Consumer)(CreateWorldScreen.java:574) at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void tryApplyNewDataPacks(net.minecraft.server.packs.repository.PackRepository,boolean,java.util.function.Consumer)(CreateWorldScreen.java:564) at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void lambda$openDataPackSelectionScreen$8(net.minecraft.server.packs.repository.PackRepository)(CreateWorldScreen.java:536) at net.minecraft.client.gui.screens.packs.PackSelectionModel.void commit()(PackSelectionModel.java:56) at net.minecraft.client.gui.screens.packs.PackSelectionScreen.void onClose()(PackSelectionScreen.java:94) at net.minecraft.client.gui.screens.packs.PackSelectionScreen.void lambda$init$1(net.minecraft.client.gui.components.Button)(PackSelectionScreen.java:124) at net.minecraft.client.gui.components.Button.void onPress()(Button.java:96) at net.minecraft.client.gui.components.AbstractButton.void onClick(double,double)(AbstractButton.java:43) at net.minecraft.client.gui.components.AbstractWidget.boolean mouseClicked(double,double,int)(AbstractWidget.java:141) at net.minecraft.client.gui.components.AbstractWidget.void updateWidgetNarration(net.minecraft.client.gui.narration.NarrationElementOutput)(AbstractWidget.java:141) at net.minecraft.client.gui.components.events.ContainerEventHandler.boolean mouseClicked(double,double,int)(ContainerEventHandler.java:38) at net.minecraft.client.gui.components.events.ContainerEventHandler.void setFocused(net.minecraft.client.gui.components.events.GuiEventListener)(ContainerEventHandler.java:38) at net.minecraft.client.MouseHandler.void lambda$onPress$0(boolean[],net.minecraft.client.gui.screens.Screen,double,double,int)(MouseHandler.java:111) at net.minecraft.client.gui.screens.Screen.void wrapScreenError(java.lang.Runnable,java.lang.String,java.lang.String)(Screen.java:429) at net.minecraft.client.MouseHandler.void onPress(long,int,int,int)(MouseHandler.java:111) at net.minecraft.client.MouseHandler.void lambda$setup$4(long,int,int,int)(MouseHandler.java:189) at net.minecraft.util.thread.BlockableEventLoop.void execute(java.lang.Runnable)(BlockableEventLoop.java:110) at net.minecraft.client.MouseHandler.void lambda$setup$5(long,int,int,int)(MouseHandler.java:189) at org.lwjgl.glfw.GLFWMouseButtonCallbackI.null callback(null)(GLFWMouseButtonCallbackI.java:43) at org.lwjgl.system.JNI.null invokeV(null)(JNI.java) at org.lwjgl.glfw.GLFW.null glfwWaitEventsTimeout(null)(GLFW.java:3509) at com.mojang.blaze3d.systems.RenderSystem.void limitDisplayFPS(int)(RenderSystem.java:178) at net.minecraft.client.Minecraft.void runTick(boolean)(Minecraft.java:1327) at net.minecraft.client.Minecraft.void run()(Minecraft.java:898) at net.minecraft.client.main.Main.void main(java.lang.String[])(Main.java:256) [Render thread/WARN]: Failed to validate datapack java.util.concurrent.CompletionException: net.minecraft.ReportedException: Registry Loading at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332) ~[?:?] at java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:674) ~[?:?] at java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:662) ~[?:?] at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2200) ~[?:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void applyNewPackConfig(net.minecraft.server.packs.repository.PackRepository,net.minecraft.world.level.WorldDataConfiguration,java.util.function.Consumer)(CreateWorldScreen.java:604) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void tryApplyNewDataPacks(net.minecraft.server.packs.repository.PackRepository,boolean,java.util.function.Consumer)(CreateWorldScreen.java:564) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void lambda$openDataPackSelectionScreen$8(net.minecraft.server.packs.repository.PackRepository)(CreateWorldScreen.java:536) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.packs.PackSelectionModel.void commit()(PackSelectionModel.java:56) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.packs.PackSelectionScreen.void onClose()(PackSelectionScreen.java:94) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.packs.PackSelectionScreen.void lambda$init$1(net.minecraft.client.gui.components.Button)(PackSelectionScreen.java:124) ~[24w34a.jar:?] at net.minecraft.client.gui.components.Button.void onPress()(Button.java:96) ~[24w34a.jar:?] at net.minecraft.client.gui.components.AbstractButton.void onClick(double,double)(AbstractButton.java:43) ~[24w34a.jar:?] at net.minecraft.client.gui.components.AbstractWidget.boolean mouseClicked(double,double,int)(AbstractWidget.java:141) ~[24w34a.jar:?] at net.minecraft.client.gui.components.AbstractWidget.void updateWidgetNarration(net.minecraft.client.gui.narration.NarrationElementOutput)(AbstractWidget.java:141) ~[24w34a.jar:?] at net.minecraft.client.gui.components.events.ContainerEventHandler.boolean mouseClicked(double,double,int)(ContainerEventHandler.java:38) ~[24w34a.jar:?] at net.minecraft.client.gui.components.events.ContainerEventHandler.void setFocused(net.minecraft.client.gui.components.events.GuiEventListener)(ContainerEventHandler.java:38) ~[24w34a.jar:?] at net.minecraft.client.MouseHandler.void lambda$onPress$0(boolean[],net.minecraft.client.gui.screens.Screen,double,double,int)(MouseHandler.java:111) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.Screen.void wrapScreenError(java.lang.Runnable,java.lang.String,java.lang.String)(Screen.java:429) ~[24w34a.jar:?] at net.minecraft.client.MouseHandler.void onPress(long,int,int,int)(MouseHandler.java:111) ~[24w34a.jar:?] at net.minecraft.client.MouseHandler.void lambda$setup$4(long,int,int,int)(MouseHandler.java:189) ~[24w34a.jar:?] at net.minecraft.util.thread.BlockableEventLoop.void execute(java.lang.Runnable)(BlockableEventLoop.java:110) ~[24w34a.jar:?] at net.minecraft.client.MouseHandler.void lambda$setup$5(long,int,int,int)(MouseHandler.java:189) ~[24w34a.jar:?] at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:43) [lwjgl-glfw-3.3.3.jar:build 5] at org.lwjgl.system.JNI.null invokeV(null)(JNI.java) ~[lwjgl-3.3.3.jar:build 5] at org.lwjgl.glfw.GLFW.glfwWaitEventsTimeout(GLFW.java:3509) [lwjgl-glfw-3.3.3.jar:build 5] at com.mojang.blaze3d.systems.RenderSystem.limitDisplayFPS(SourceFile:178) [24w34a.jar:?] at fil.c(SourceFile:1327) [24w34a.jar:?] at fil.f(SourceFile:898) [24w34a.jar:?] at net.minecraft.client.main.Main.main(SourceFile:256) [24w34a.jar:?] Caused by: net.minecraft.ReportedException: Registry Loading at net.minecraft.resources.RegistryDataLoader.net.minecraft.ReportedException createReportWithBriefInfo(java.util.Map)(RegistryDataLoader.java:267) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.ReportedException logErrors(java.util.Map)(RegistryDataLoader.java:232) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.resources.RegistryDataLoader$LoadingFunction,java.util.List,java.util.List)(RegistryDataLoader.java:199) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.server.packs.resources.ResourceManager,java.util.List,java.util.List)(RegistryDataLoader.java:164) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.void lambda$load$2(net.minecraft.server.packs.resources.ResourceManager,net.minecraft.resources.RegistryDataLoader$Loader,net.minecraft.resources.RegistryOps$RegistryInfoLookup)(RegistryDataLoader.java:164) ~[24w34a.jar:?] at net.minecraft.server.WorldLoader.java.util.concurrent.CompletableFuture load(net.minecraft.server.WorldLoader$InitConfig,net.minecraft.server.WorldLoader$WorldDataSupplier,net.minecraft.server.WorldLoader$ResultFactory,java.util.concurrent.Executor,java.util.concurrent.Executor)(WorldLoader.java:41) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void applyNewPackConfig(net.minecraft.server.packs.repository.PackRepository,net.minecraft.world.level.WorldDataConfiguration,java.util.function.Consumer)(CreateWorldScreen.java:574) ~[24w34a.jar:?] ... 22 more Caused by: java.lang.IllegalStateException: Failed to load registries due to errors at net.minecraft.resources.RegistryDataLoader.net.minecraft.ReportedException createReportWithBriefInfo(java.util.Map)(RegistryDataLoader.java:251) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.ReportedException logErrors(java.util.Map)(RegistryDataLoader.java:232) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.resources.RegistryDataLoader$LoadingFunction,java.util.List,java.util.List)(RegistryDataLoader.java:199) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.net.minecraft.core.RegistryAccess$Frozen load(net.minecraft.server.packs.resources.ResourceManager,java.util.List,java.util.List)(RegistryDataLoader.java:164) ~[24w34a.jar:?] at net.minecraft.resources.RegistryDataLoader.void lambda$load$2(net.minecraft.server.packs.resources.ResourceManager,net.minecraft.resources.RegistryDataLoader$Loader,net.minecraft.resources.RegistryOps$RegistryInfoLookup)(RegistryDataLoader.java:164) ~[24w34a.jar:?] at net.minecraft.server.WorldLoader.java.util.concurrent.CompletableFuture load(net.minecraft.server.WorldLoader$InitConfig,net.minecraft.server.WorldLoader$WorldDataSupplier,net.minecraft.server.WorldLoader$ResultFactory,java.util.concurrent.Executor,java.util.concurrent.Executor)(WorldLoader.java:41) ~[24w34a.jar:?] at net.minecraft.client.gui.screens.worldselection.CreateWorldScreen.void applyNewPackConfig(net.minecraft.server.packs.repository.PackRepository,net.minecraft.world.level.WorldDataConfiguration,java.util.function.Consumer)(CreateWorldScreen.java:574) ~[24w34a.jar:?] ... 22 moreAnd then lists the IDs that were listed, but are missing.
Expected behavior is that if these IDs are not present among any loaded data packs, because they are not required, the game will ignore them for these tags and validate without them.
Steps to recreate:
- Create a tag in <namespace>/tags/worldgen/biome
- Make this tag include at least one biome that does not exist, as an object with "required": false. For example, "test:test"
- Attempt to load the data pack in a world
- Observe that the game attempts to load the world in Safe Mode, and the output log has produced the above error.
- Perform the same test in 1.21.1 and note that the data pack validates as expected.
Example tag for convenience:
{ "values": [ "minecraft:plains", { "id": "test:test", "required": false } ] }
I assume this bug is also responsible for decorators not generating in custom dimensions.
No it doesn't, wayne, you're not helping.
Even if it reduces the lag when crossing chunk borders (which I did not find to be the case, at least not any more significantly than just exploring with the output log closed instead of open), the biomes still become null in-game.
@Jim Also this bug is actually the cause of that one you requested to be reopened, maybe pay a little attention and do some actual troubleshooting to determine where the two add up.
That issue is the actual and direct cause of this one.
@Jim Because your description of the problem, how it presents and steps to recreate match with the troubleshooting that's been done by myself and others in pursuit of understanding this bug. You just didn't think hard enough and look far enough before deciding to complain that Mojang was being "unacceptable."
Bro, can you shut up @Jim? You misunderstood the cause of your bug, the moderation team's quite intentional and reasonable manner of response to it, the purpose and intent of this bug, and the actual state of experimental custom world features. But that's okay, no one was holding it against you until now. Quit while you're behind and move on with everyone's lives.
Bug persists in 24w35a