Fabric API

FabricRecipeProvider.getRecipeIdentifier replaces the namespace of the recipe with the mod id of the data generator:

fabric/fabric-data-generation-api-v1/src/main/java/net/fabricmc/fabric/api/datagen/v1/provider/FabricRecipeProvider.java

Lines 101 to 103 in 7d882bf

    
           protected Identifier getRecipeIdentifier(Identifier identifier) { 
        
           	return new Identifier(output.getModId(), identifier.getPath()); 
        
           }

This can easily lead to invalid recipe advancements where the advancement's default has_the_recipe criterion still references the original namespace.

I think the proper fix is to remove getRecipeIndentifier entirely, and inject into offerTo(Consumer, String) to make it use the modid of the current running FabricRecipeProvider instead of minecraft (accessed via ThreadLocal).

Since this is a breaking change (but necessary due to an unfixable oversight in the API, imo), we should only do this in 1.20. The behavior will remain broken in older versions.

@FabricMC/fabric-triage thoughts?

The current implementation allows you to overwrite vanilla recipes, which is a common request. With the removal of FabricRecipeProvider::getRecipeIdentifier this will no longer be possible

Maybe a better fix would be to deprecate the offerTo that doesn't take an Identifier. A bit more verbose for modders, but it would fix recipe advancements. Maybe we can log a warning.

	protected Identifier getRecipeIdentifier(Identifier identifier) {
	return new Identifier(output.getModId(), identifier.getPath());
	}

Share to