When you change the output amount, for example unlocks_crafts = { "crafts:plant_fibre" } to unlocks_crafts = { "crafts:plant_fibre" 3 }, you create a potential domino effect where the next recipe in a chain might not set always_known = true, and instead depend on an award to unlock it.
If the award in question has unlocks_crafts = { "crafts:plant_fibre" } in the trigger, all of a sudden it's broken and needs to be changed to unlocks_crafts = { "crafts:plant_fibre 3" }, due to the change in the crafting registration.
This could easily lead to unintentional breakages when trying to edit recipes for game balance.
A second issue due to this is that if you define two different crafting recipes for an item and making x amount of that item is the unlock for another recipe, you can't make sure the total needed for the unlock increments with each item made.
A better system would be to have crafting recipes unlock based on total made, not based on total uses of a given recipe.
When you change the output amount, for example
unlocks_crafts = { "crafts:plant_fibre" }
tounlocks_crafts = { "crafts:plant_fibre" 3 }
, you create a potential domino effect where the next recipe in a chain might not setalways_known = true
, and instead depend on an award to unlock it.If the award in question has
unlocks_crafts = { "crafts:plant_fibre" }
in the trigger, all of a sudden it's broken and needs to be changed tounlocks_crafts = { "crafts:plant_fibre 3" }
, due to the change in the crafting registration.This could easily lead to unintentional breakages when trying to edit recipes for game balance.
A second issue due to this is that if you define two different crafting recipes for an item and making x amount of that item is the unlock for another recipe, you can't make sure the total needed for the unlock increments with each item made.
A better system would be to have crafting recipes unlock based on total made, not based on total uses of a given recipe.