Hmmm. Ok, i agree it. Both models needed.
Tag system is not needed, unlike list system. It could help and be useful, but it’s not necessary.
Woods soup from and -> Woods soup from meat and veggy. Or just "woods soup" and list "made from" lower.
But there are many examples where we want those materials visible, mostly for allergies and later for cannibalism.
And shortening “meat jerky” to just “meat” would require keeping those “short names” somewhere.
So we’d need a list of what can we shorten item names to or generate them from tags somehow.
And in case of tags, we’d need a good way to limit the name, to prevent names like “fish soup from meat, bone, wheat and eggs”.
Why not for weight?
Because water content changes a lot. Dehydrated food loses a lot of weight, but shouldn’t result in lighter soups.
Nutrition should also be retained in case of some foods - soup made from dehydrated meat should have as much nutrition as one from rehydrated meat (dehydrated and then rehydrated back).
Yes, it is ton of work to rewriting 200k of copypaste with food recipes, but it much better, that do few more.
Globalized lists would be less work, though. And they would still solve the repetition.
tags : [...],
craft_tags: [ "SWEET_VEGGY", "IRRADIATED_VEGGY", "DESSERT"],
groups: [""FRIDGE_FOOD", "MANSION_FRIDGE"]
You’d still have a big block for almost every item. It would make individual files big and “dense” in those tags.
Few lines JS code.
How would you get all the items that you want to add the new tag to?
You’d still have to build a list, just that you’d only use it to add tags to those items and then drop it.
Are you real coder? Covers arrays from item_groups to array for each item or back - half hour of coding time with JS/Perl. Or you think do this with text editor?
It’s not as simple as that.
Consider lists with weights such as item_groups. Those can’t be inverted easily. And we need those weights.
Then there’s the issue of replacing a large part of data in one go - we generally don’t merge changes so huge that they can’t be displayed in github UI, as this means that:
[ul][li]The PR is huge and hard to review[/li]
[li]To review the PR, we need to download it first and use an external diff program[/li]
[li]Testing such a PR may take a lot of time[/li][/ul]
So it would most likely require multiple PRs to convert the data.
Doing it in “one go” rather than breaking it up would require a very good reason to make an exception. I don’t see a good enough reason to do that. And Kevin would probably be stricter than me about a good reason to break our project rules.
You have no any system for balance something, except text editor.
Recipes. Our current recipes are roughly balanced by the fact that we compare inputs and outputs manually.
If we added an automatic system for stats out of components’ stats, we’d have to make sure it gives proper results.
For example, that soup made from dehydrated meat doesn’t lose nutrition compared to same soup made from same meat with water added to rehydrate it.
As i say both methods has good and bad sizes.
Item tags have the advantage that only one file has to be changed per new item/recipe, but they mean that maintenance and listing may require scripts and they don’t allow weights.
Plus, item tags would take much more work.
I see those two cases as roughly comparable. I’d prefer globalized lists, but I’d be fine with tags.
But the amount of work required for item tags would be much greater than one for globalized lists.
