In this mod, recipes are created using recipe JSON files, using Vanilla Minecraft's datapack system. All in-world recipes are thus read from the data/<namespace>/recipes directory of a datapack (with <namespace> being any valid resource location namespace, like minecraft, interactio or my_cool_recipes). Because this system is simply based on Vanilla datapacks, you can refer to the relevant Minecraft Wiki entries for a general guide on Datapack and Recipe syntax.

There are, of course, a couple of differences though, for instance, in-world recipes aren't displayed in the vanilla recipe book (for more or less obvious reasons), so the group identifier doesn't actually do anything. Also, thanks to Forge, in-world recipes support NBT Crafting (i.e. crafting output items that have certain NBT data) by adding an optional nbt json object to any item stack outputs. One more thing to note is that whenever an ID is required and you want to use something from vanilla, you can omit the "minecraft:" part of the id as it's automatically added by the parser.

For recipes with item inputs, so called RecipeIngredients are used. RecipeIngredients are a bit like vanilla ingredients (i.e. they support item tags and single items as well as any combination of the two in the form of an array), however they may carry more useful bits of information (for example a count, which is needed because vanilla ingredients only support inputs with a stack size of 1 and a return_chance, which determines the likelihood that the ingredient is not used up in the craft). Both of these properties are optional, with count being 1 and return_chance being 0 by default, so if you really wanted to, you could just use vanilla recipe ingredient syntax and be just fine.

In JSON, a RecipeIngredient might look like this:

{
  "item": "minecraft:spruce_log",
  "count": 3,
}

or like this

{
  "tag": "forge:ores/gold",
  "count": 4,
  "return_chance": 0.75
}

and in some cases, for example if you want to supply an array of possible inputs, you may need to use this:

{
  "ingredient": [
    {
      "item": "minecraft:redstone"
    },
    {
      "tag": "forge:ingots/iron"
    }
  ],
  "count": 10,
  "return_chance": 0.2
}

(I don't really recommend using that last one, though, it makes recipes become really bloated really quickly. Just add the components you need to a single tag if you want to use them in a recipe like this.)

On Forge, Ingredients can also have custom types, so you could for example use something like this:

{
  "ingredient": {
    "type": "forge:nbt", // custom ingredient type, only works on forge
    "item": "ceramics:clay_bucket",
    "count": 1,
    "nbt": ""
  }
}

to accept only items with some specific nbt data (so in this case, that'd mean empty clay buckets (no nbt) specifically).

FluidIngredients are supposed to be an analogue to Vanilla (item) Ingredients, and as such mirror its syntax. You can supply it either a single fluid, a fluid tag, or an array containing any combination of the previous two. As such, a possible FluidIngredient might look like this:

{
  "fluid": "water" // (Single Fluid "minecraft:water")
}

...

{
  "tag": "lava" // (Fluid Tag "minecraft:lava")
}

...

// Array that takes both Latex from industrialforegoing as well as anything contained in the tag "modpack:oils"
[
  {
    "fluid": "industrialforegoing:latex"
  },
  {
    "tag": "modpack:oils"
  }
]

BlockIngredients are also a thing now and work almost identically to FluidIngredients and vanilla Ingredients: Just like before, you can pass in blocks, tags and arrays containing any of the two.^

One important thing to note is that you will need to supply block ids and/or tags, which may differ from their item form counterparts! (make sure to use the /item_info command if you are unsure what the block id might be)

{
  "block": "netherrack" // (**Block** id "minecraft:netherrack")
}

...

{
  "tag": "minecraft:logs" // (**Block** Tag "minecraft:logs")
}

...

[
  {
    "block": "minecraft:stone"
  },
  {
    "tag": "minecraft:stripped_logs"
  }
]

Recipe outputs in this mod are weighted, which means that you can have different outputs occurring at different chances, as well as having no output at all (an "empty weight"). The higher an output's weight is, the more likely it is to be chosen out of the pool of all entries (including the empty weight). Depending on the recipe type, you may also roll the same weighted output multiple times (by providing a rolls key with a number) as well as determine that for multiple rolls, each possible entry may only be chosen once (this is called a unique roll and must be declared with a corresponding flag).

This means that having something like this in JSON:

{
    "entries": [
      {
        "result": {
          "item": "minecraft:diamond",
          "count": 2
        },
        "weight": 10
      },
      {
        "result": {
          "item": "minecraft:white_wool",
          "count": 5
        },
        "weight": 7
      }
    ],
    "empty_weight": 83,
    "rolls": 10
  },

results in a 10% chance of 2 diamonds being produced, a 7% chance of 5 white wool being produced, and an 83% chance of nothing being produced, with the output being rolled 10 times each time the recipe is successfully crafted.

WeightedOutputs currently support item, block and fluid results using the appropriate JSON syntax (for concrete examples, see the different input ingredient types, everything except for tags is supported), but in theory, addons can add anything they want as a weighted output so long as it has an appropriate IEntrySerializer. (see WeightedOutput, IEntrySerializer)