Move recipe book categorization from the recipe entry to the cookbook entry, add recipe_list json object

[I-am-Erk]

Is your feature request related to a problem? Please describe.

Recipe book learning is currently defined in each recipe, eg.

"book_learn": [ [ "cookbook_foodfashions", 5 ], [ "baking_book", 2 ] ],

On an individual recipe level this is nice, because it allows the recipe creator to add cookbook info in a single change. However, on a balancing level, it's a nightmare. It makes it almost impossible to audit and improve recipe lists, because they're stored all over the place inconsistently. It also makes it very hard to check recipe consistency, ie. making sure that particular books follow a consistent theme and consistent recipe difficulty.

FInally, it has led to a few popular books being way overloaded for recipes, many of which are quite ridiculous in context.

As we add more recipe books as part of the Autolearn Audit, this just has to change.

Describe the solution you'd like

1. Create a new JSON entity, recipe_list. Recipe lists would be like item groups, a list of recipes that could be included in whatever item calls the list. Recipes can have a probability entry, although books will often ignore this. see 3.

2. Add recipe_list(s) to the book definition, eg:

  {
    "id": "adv_chemistry",
    "type": "BOOK",
    "name": { "str": "Advanced Physical Chemistry", "str_pl": "copies of Advanced Physical Chemistry" },
    "description": "A university-level textbook on advanced principles of chemistry, both organic and inorganic.",
    "material": [ "paper" ],
    "skill": "cooking",
    "recipes": [ { "list": "reclist_chemistry", "recipe_count": "ALL", "learn_difficulty": 1 } ]
  },

learn_difficulty represents how hard it is to get recipes out of this book. It can be a positive or negative number. The skill level required to learn a recipe in the list will be increased/decreased by this number.

3. OPTIONAL FEATURE / STRETCH GOAL: Recipe_count: Allows each book/magazine to include a randomly selected group of recipes from a larger list. "ALL" means that everything in the list will be included in the book. The other option is a format like "recipe_count": [ 3, 6 ] means the book will have 3 to 6 recipes randomly selected from the list based on their listed weights. This is ideal for magazines, allowing cooking magazines to provide different recipes in each issue. Implementing this feature may be a bit tricky as it will require keeping different issues of a magazine separate from each other.

4. Create a python script to automatically generate these lists and push them into the appropriate recipe books, creating a huge amount of code churn and a painstaking review job. We could either generate lists for each existing recipe book, or we could generate lists by which proficiencies have which recipe, or both. Whatever the case, the final result will need a fair bit of human editing once done.

Additional context

Previously I considered having recipes sorted by proficiency but I think that adds unnecessary complexity.

[ymber]

Duplicate of #36563. Mine was a glorified todo note so we should probably keep this one.

[I-am-Erk]

Woops, that is definitely on me

[jkraybill]

It would be nice if mods were still allowed to use this "old" method for adding a single new recipe to multiple books, or at least if the new method allowed mods to do that in some simple additive way without having to override/extend every book definition they want to modify?

[I-am-Erk]

belated @jkraybill: for in repo mods, we'd roll their recipe lists into whatever PR(s) added new ones. Personally I don't really think the old behaviour should remain supported or we'll wind up with a huge mess of mixed recipe modes as people try to make individual exceptions, but ultimately Kevin would be the one to decide on that.

[Night-Pryanik]

No discussion in almost a year, closing.