Recipe API

[TheCodedOne]

Discussion around the recipe API.

The API should contain

• Custom recipe types
• Generic ingredients
• Dynamic code-based recipes
• Resource ingredients

Allowing items to replace other items (item/fluid/... containers for example) is not in scope (will either be added as a change to this api or as a different api).

[Bluexin]

One thing to also think about I think would be how to efficiently match against recipes. By generic ingredients, do you mean a system where people could add their own custom ingredient types ? (like a gas, or some special handling for containers)

[TheCodedOne]

Generic ingredients as in the ability to set a Fluid as an input or output, or potentially custom things if people choose

[Bluexin]

So I was imagining something like this for ingredients then :

• generic Ingredient<INPUT> interface
  • input matches ?
  • consume from input
• StackTagsIngredient : Ingredient<ItemStack> : used to match ItemStacks based on their tags
  • would hold one or more tags to match ItemStacks against
  • would have a quantity
  • input matches ? -> using tags + quantity
  • consume from input -> shrink stack, which can become empty
• ContainedFluidTagsIngredient : Ingredient<ItemStack> : used to match ItemStacks containing fluids based on their tags
  • would hold one or more tags to match ItemStack's fluid(s) against
  • would have a quantity
  • input matches ? -> get the fluid from the container, then match it using tags + quantity
  • consume from input -> reduce the fluid amount in the container, which can become empty
• FluidTagsIngredient : Ingredient<FluidStack> : used to match FluidStacks based on their tags
  • would hold one or more tags to match FluidStacks against
  • would have a quantity
  • input matches ? -> using tags + quantity
  • consume from input -> reduce the fluid amount in the stack, which can become empty

etc. It should be fairly straight forward to add custom ingredient types later too. Wdyt ?

PS: I'm not 100% clear on how tags work, so I assumed similar to oreDict PS2: Idk if we have a fluid api here, but I just described something basic to show how it'd work PS3: I'm terrible at naming things

[Bluexin]

This would allow people to make an ingredient for their own custom /dev/null by making a custom Ingredient that would check for stacks of their item and be able to retrieve the correct info from.

Or maybe this specific use case shows we should split resolving ItemStacks to Ingredients or something. Where you could register multiple resolvers for the same input, each handling translating the input to one of the possible Ingredients it can be

For example, we wouldn't have ContainedFluidTagsIngredient, we'd only register one resolver to translate ItemStacks with a contained fluid to a FluidTagsIngredient.

[TheCodedOne]

Ingredients wouldn't be used for actual logic, they should be for defining the required items in the json. allowing a /dev/null to be used as an input should be a different API which allows the dev null to impersonate the required item, same should go for fluid tanks.

[Bluexin]

{
  "type": "minecraft:smelting",
  "ingredient": {
    "resource": "copper:ingot"
  }
}

{
  "type": "minecraft:smelting",
  "ingredient": {
    "resource": {
      "material": "copper",
      "type": "ingot"
    }
  }
}

People on discord seemed to prefer the second, although with some worry about verbosity