Raw Resource used to be a full element of the recipes field. Requiring it to be an empty recipe that has a single requirement of 0 of itself. This was, and still is, necessary so that a user can select that a particular resource be considered as a raw resource in the recipe selection of the calculator itself. Over time it became clear that this was tedious so a simple macro was added to allow for only defining - recipe_type: Raw Resource as the entire recipe and having the rest of the fields automatically populate from the builder. While significantly better then the previous iteration this field is still required on every single item. At the end of the day the only thing that really matters is "is this recipe supposed to be a raw resource by default". The Default recipe is the first item in the recipe list, so if Raw Resource was the first recipe then it was considered the default. However if it was not the first item then it did not matter where in the recipe list it was found because a user can select it like any other alternate recipe.
This leaves two competing options. Lets take the following examples:
Diamond Sword:
recipes:
- output: 1
recipe_type: Crafting
requirements:
Stick: -1
Diamond: -2
- recipe_type: Raw Resource
Iron Ingot:
recipes:
- recipe_type: Raw Resource
- output: 1
recipe_type: Smelting
requirements:
Iron Ore: -1
Fuel: -1
Option 1: Remove Raw Resource from the recipes list and move it to an optional top-level field
Option 1 allows for a clearer distinction that "this item is considered a raw resource" and may be easier for new users to grok when editing the resource list. Additionally it acts as a strict rule for how and where Raw Resources are defined, only as this variable. However, with that benefit it also completely removes the ability to have a raw resource be anything other then "the first recipe" or "the last recipe".
I think the utility of being able to customize the ordering of alternate resources, specifically the ordering of the raw resource option, is not huge. And the grokability of a top-level field outweighs the possible use case of wanting to order the raw resource to be say the 3rd item in the recipe selection list.
Raw Resource used to be a full element of the
recipesfield. Requiring it to be an empty recipe that has a single requirement of0of itself. This was, and still is, necessary so that a user can select that a particular resource be considered as a raw resource in the recipe selection of the calculator itself. Over time it became clear that this was tedious so a simple macro was added to allow for only defining- recipe_type: Raw Resourceas the entire recipe and having the rest of the fields automatically populate from the builder. While significantly better then the previous iteration this field is still required on every single item. At the end of the day the only thing that really matters is "is this recipe supposed to be a raw resource by default". The Default recipe is the first item in the recipe list, so if Raw Resource was the first recipe then it was considered the default. However if it was not the first item then it did not matter where in the recipe list it was found because a user can select it like any other alternate recipe.This leaves two competing options. Lets take the following examples:
Option 1: Remove Raw Resource from the
recipeslist and move it to an optional top-level fieldOption 2: Make Raw Resource completely optional, and if it does not exist add it as the final element in the recipe list
Option 1 allows for a clearer distinction that "this item is considered a raw resource" and may be easier for new users to grok when editing the resource list. Additionally it acts as a strict rule for how and where Raw Resources are defined, only as this variable. However, with that benefit it also completely removes the ability to have a raw resource be anything other then "the first recipe" or "the last recipe".
I think the utility of being able to customize the ordering of alternate resources, specifically the ordering of the raw resource option, is not huge. And the grokability of a top-level field outweighs the possible use case of wanting to order the raw resource to be say the 3rd item in the recipe selection list.