Edit:

The ore compat system has changed since its initial conception.

Please see #59

If you have mod suggestions for wood and ore recipe compat, please leave a comment!

I want to create some built-in compat for other mods' wood and ore, specifically:

• chopping/saw recipes for log/plank and plank/slab
• bloomery recipes for ore/nugget

So far, this is the list:

Wood

• Betweenlands
• Biomes O Plenty
• Botania
• Erebus
• Extra Biomes
• Forestry
• Misty Lands
• Natura
• Plants
• Terraqueous
• Traverse
• Twilight forest

Ore

• [?] Geolosys
• Astral Sorcery
• Base Metal
• Base Mineral
• Dense Ores
• Forestry
• IC2
• Immersive Engineering
• Metallurgy 4 Reforged
• Modern Metal
• Nether Ores
• Netherending Ores
• Tech Reborn
• Thermal Foundation
• Tinker's Construct (Ardite and Cobalt)

Wood:

Biomes O Plenty
Forestry
Plants
Terraqueous
Extra Biomes
Then there's all those mods that add a custom dimension with trees etc that you may not want to bother with:
Twilight forest
Erebus
Betweenlands
Misty Lands

Ore
Forestry (again)
IC2
netherendingores/nether ores and all the other mods that add nether and/or end variations of vanilla ores.
Dense ores
Geolosys would be messy but might appeal to the same people

Ore:
Metallurgy 4 reforged
tech reborn
Astral Sorcery
base metal
base mineral
modern metal
tinker's construct(ardite and cobalt)

Trees:

Rustic
Extra trees (Binnie's Mods, a Forestry expansion)
Defiled Lands has a tree. Also some ores.
Thaumcraft has two trees.
Totemic - Cedar
Zoocraft Discoveries - Arctic Pine
And then there's Dynamic Trees, and all its add-ons.

Atum has two trees, and some ores.
Erebus has trees and ores
Heat and Climate has trees and ores.

More ores:
Quark
Stargate Network
Ice and Fire
Nether Expansion (NetherEx)
Embers

Wood:
Rustic
Forestry
Traverse
Thaumcraft

Wood

Wood compat recipes for the chopping block, and sawmill if inheritance is enabled, would be generated by the mod and supplied to the pack-dev as a .json list. Similar to the existing .json lists provided in the mod's config folder, this list would be generated twice as a Generated and Custom .json file. The Generated file will always have the up-to-date list generated by the mod, and the Custom file will be what the mod actually reads.

This would allow pack-devs to make changes to the Custom file and also be able to review any changes to the Generated file when mods are added / removed. Additions to the Generated file could simply be copied into the Custom file or the Custom file could be deleted and it would just regenerate on next load.

This is an example of what it might look like with only vanilla items:

{
  "minecraft": { // mod id
    "planks": {
      "log:0": "planks:0", // input: output (doesn't need mod id)
      "log:1": "planks:1",
      "log:2": "planks:2",
      "log:3": "planks:3",
      "log2:0": "planks:4",
      "log2:1": "planks:5"
    },
    "slabs": {
      "planks:0": "wooden_slab:0", // input: output (doesn't need mod id)
      "planks:1": "wooden_slab:1",
      "planks:2": "wooden_slab:2",
      "planks:3": "wooden_slab:3",
      "planks:4": "wooden_slab:4",
      "planks:5": "wooden_slab:5"
    }
  }
}

In the case that a mod is removed and its entry is not removed from the Custom file, it would simply be ignored and those recipes wouldn't generate.

Ores (Bloomery recipes)

Ores are a little trickier because, in a modded environment, there can be many duplicate ores and nuggets.

This idea uses the same .json generation as the other .json content; the Generated and Custom files. Lists of nuggets would be provided under oredict names and the mod would just choose the first available nugget in the list. This would let a pack-dev simply delete the nuggets that they don't want to use.

{
  "oreIron": [
    "minecraft:iron_nugget"
    ...
  ],
  "oreGold": [
    "minecraft:gold_nugget"
    ...
  ]
}

This would handle the bloomery recipes, but slag will also have to be generated for modded ores as well. It will actually have to be generated first, before the bloomery recipes are made.

I see the lang key names being the tricky bit here. The generated slag uses lang keys provided in the .json file.

The mod could suss out slag entries that need to be generated by looking at the non-empty oredict keys in the previous ore file. Internally, the registryName and color data would be provided based on oredict. The langKey entry would need to be derived from any available ore under the oreIron oredict key.

The mod already has slag .json files that look like this:

"list": [
  {
    "registryName": "iron",
    "langKey": "tile.oreIron",
    "color": "d8af93"
  },
  {
    "registryName": "gold",
    "langKey": "tile.oreGold",
    "color": "fcee4b"
  }
]

One drawback to this approach is that if a lang key is derived from a mod's ore and that mod is later removed, the lang key in the Custom file would no longer work.

I guess at that point, it'd be up to the pack-dev to address that.

More Notes

Slag needs to be generated before bloomery recipes.

PreInitialization:
  - Generate slag .json
  - Generate slag from slag .json
  + Generate slag / bloomery compat .json
  + Generate slag from slag / bloomery compat .json

Initialization:
  ? Generate internal bloomery recipes
  + Generate bloomery recipes from slag / bloomery compat .json

Need to store generated slag item / block referenced by the oredict name that spawned it in order to know which slag items and blocks to use when generating the bloomery recipes.

During pre-init, generate json before slag generation:

{
  "oreIron": { // oredict
    "color": "d8af93" // color of the generated slag
    "langKey": [
      "minecraft:tile.oreIron", // first available entry is used
      "domain:langkey",
      "domain:langkey",
      "domain:langkey"
    ],
    "output": [
      "minecraft:iron_nugget", // first available entry is used
      "domain:path",
      "domain:path",
      "domain:path"
    ],
  },
  "oreGold": {
    "color": "fcee4b",
    "langKey": {
      "minecraft": "tile.oreGold"
    }
    "output": [
      "minecraft:gold_nugget"
    ],
  }
}

Ore:
GregTech: Community Edition
Wood:
GregTech: Community Edition

Beware it has an absolute lot of ores, and not all of them have ingots / nuggets.

The ore compat system has changed since its initial conception.

Please see #59