You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Decorated Pot recipe does not preserve data of materials #14386
Crafting a pottery sherd with a sherd or brick that contains custom data (I.e one that has been renamed in an anvil) Should preserve that data when the pot is shattered with a weapon.
Observed/Actual behavior
Pottery sherds and bricks lose all data except for their identifier, including any custom provides_pottery_pattern component.
Steps/models to reproduce
Rename four bricks in an anvil.
Craft a decorated pot with renamed bricks.
In survival, break the pot with a tool.
Observe bricks.
Plugin and Datapack List
No Plugins or Datapacks
Paper version
This server is running Paper version 26.3-186-main@b5eb5e0 (2026-10-14T18:20:35Z) (Implementing API version 26.3.build.186-stable)
Other
Prior to 26.3, this was expected vanilla behavior. However, pottery sherds were made to conserve in 26.3 snapshot 1.
Failure here is from SPIGOT-4638 in net.minecraft.world.item.crafting.RecipeManager#getRecipeFor(net.minecraft.world.item.crafting.RecipeType<T>, I, net.minecraft.world.level.Level) which prioritizes later registered recipes (to allow plugin overriding vanilla ones).
This breaks selecting the complex recipe which supports data transferal and instead goes to the normal shaped one.
Fixing this is non trivial without breaking plugin priority for equally matching recipes.
Maybe we can require plugins to pass a override boolean or something for recipe overriding like that? I feel like overriding vanilla should be an intentional choice by a plugin, and not "oops I forgot this vanilla recipe exists" (definitely never happened to me).
Definitely keeping (and not delaying the fix) for this behaviour. It is a pretty large behaviour change imo and I am unsure how useful such an addition would be. Plugins would still be breaking, just in a different manner. I guess such a boolean would give you a bit of control over what failure mode you want to exhibit if a future version introduces a recipe that matches yours but eh. Don't think change anything defaults for a toggle on "how do I break" is a good idea.
Activity
lynxplay commentedon Oct 14, 2026
Failure here is from
SPIGOT-4638innet.minecraft.world.item.crafting.RecipeManager#getRecipeFor(net.minecraft.world.item.crafting.RecipeType<T>, I, net.minecraft.world.level.Level)which prioritizes later registered recipes (to allow plugin overriding vanilla ones).This breaks selecting the complex recipe which supports data transferal and instead goes to the normal shaped one.
Fixing this is non trivial without breaking plugin priority for equally matching recipes.
Malfrador commentedon Oct 14, 2026
Maybe we can require plugins to pass a
overrideboolean or something for recipe overriding like that? I feel like overriding vanilla should be an intentional choice by a plugin, and not "oops I forgot this vanilla recipe exists" (definitely never happened to me).lynxplay commentedon Oct 14, 2026
Definitely keeping (and not delaying the fix) for this behaviour. It is a pretty large behaviour change imo and I am unsure how useful such an addition would be. Plugins would still be breaking, just in a different manner. I guess such a boolean would give you a bit of control over what failure mode you want to exhibit if a future version introduces a recipe that matches yours but eh. Don't think change anything defaults for a toggle on "how do I break" is a good idea.