Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unobvious recipe datagen logic (not an issue, more of a discussion) #4252

Open
maityyy opened this issue Nov 26, 2024 · 2 comments
Open

Unobvious recipe datagen logic (not an issue, more of a discussion) #4252

maityyy opened this issue Nov 26, 2024 · 2 comments

Comments

@maityyy
Copy link
Contributor

maityyy commented Nov 26, 2024

I'm creating this issue primarily to share my fix and let you know that this is a known issue, but also to possibly make a change.

I'm using mojmap.

Vanilla, for creating advancements that unlock recipes, uses the namespace of the item rather than the recipe itself. You can see that in RecipeBuilder::save.

This quite unobvious logic results in recipes for items not of this mod having no real working unlock advancements!

Should the FabricRecipeProvider report this somewhere in the docs?

I previously used FabricRecipeProvider::getRecipeIdentifier when exporting a recipe, but this is no longer possible in newer versions as recipes are now created outside of FabricRecipeProvider (in RecipeGenerator impl, or in an anonymous class).

Anyway, my simple fix:

@Override
public void buildRecipes() {
    Item recipeResult = ...; // item not of this mod
    recipeBuilder(recipeResult)
        .save(output, useModNamespace(recipeResult)) // RecipeBuilder::save
}

private ResourceKey<Recipe<?>> useModNamespace(Item item) {
    return ResourceKey.create(Registries.RECIPE, ResourceLocation.fromNamespaceAndPath("modid", RecipeBuilder.getDefaultRecipeId(item).getPath()));
}
@Linguardium
Copy link

it still works as long as you design your provider in a given fashion:

public class RecipeProvider extends FabricRecipeProvider {

    public RecipeProvider(FabricDataOutput output, CompletableFuture<RegistryWrapper.WrapperLookup> registriesFuture) {
        super(output, registriesFuture);
    }

    @Override
    protected RecipeGenerator getRecipeGenerator(RegistryWrapper.WrapperLookup wrapperLookup, RecipeExporter recipeExporter) {
        return new RecipeGenerator(wrapperLookup, recipeExporter) {

            @Override
            public void generate() {
                createShaped(RecipeCategory.MISC, Items.ACACIA_BOAT)
                        .pattern("XXX")
                        .input('X',Items.COBBLESTONE)
                        .criterion("somecrit",conditionsFromItem(Items.COBBLESTONE))
//                        .criterion("someothercrit",conditionsFromItem(Items.FLINT))
                        .offerTo(exporter, RegistryKey.of(RegistryKeys.RECIPE, getRecipeIdentifier(someId));


            }
        };
    }

    @Override
    public String getName() {
        return "";
    }

}

@maityyy
Copy link
Contributor Author

maityyy commented Nov 26, 2024

We can also use Interface Injection and add our own version of RecipeBuilder::save that would use (somehow) the mod namespace (or just static util class)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants