Breaking Change: New Market Definitions
BlayTheNinth opened this issue ยท 2 comments
With the expansion of Vanilla's recipe system to lots of different recipe types, there is really not much reason anymore to use a custom data pack format. Trades could be defined as recipes and tie into Vanilla's loading systems naturally. This would also simplify integrations with recipe viewing mods like JEI or customization mods like CraftTweaker.
{
"type": "farmingforbockheads:market",
"preset": "farmingforblockheads:vanilla_saplings"
"category": "farmingforblockheads:saplings",
"result": "minecraft:oak_sapling"
"payment": {
"item": "minecraft:emerald",
"count": 3
}
}where payment is an Ingredient wrapper with a count.
Overarching overrides (like having ALL saplings cost diamonds instead of emeralds, or enabling all mushrooms) are a bit more difficult to achieve with an isolated per-item format like that, but should still be doable:
{
"type": "farmingforbockheads:market",
"preset": "farmingforblockheads:vanilla_mushrooms"
"category": "farmingforblockheads:mushrooms",
"result": "minecraft:red_mushroom"
}where "preset" refers to a string that needs to be added in the config's "presets" property in order for this recipe to be enabled, and "payment" is undefined meaning it will fall back to a defined default.
Defaults could then be defined as a separate definition, connected through the preset, though here I would go with a custom json loader since this isn't semantically one recipe unit anymore:
{
"preset": "farmingforblockheads:vanilla_mushrooms",
"defaults": {
"payment": {
"item": "minecraft:emerald"
}
}
}Similarly, categories could be defined as isolated json files:
{
"name": "Mushrooms",
"icon": {
"item": "minecraft:brown_mushroom"
}
} Bonus points if we can provide a converter script.
