Allow spoil_weight and percent_spoiled > 1

[protocol_1903]

As in title. The implementation details and how it would function differs, so I'll lay out my ideas below. I do think these ideas are related, though, so I thought to combine them here.

ItemIngredientPrototype::spoil_weight > 1

I have two ideas for how this could be implemented. The first is simple: allow it to be > 1, and the total spoil level for the recipe is the weighted sum of all ingredient spoilage levels divided by the sum of the spoil weights, so the output would always be [0, 1]. This isn't ideal, as (I think) it's a breaking change, but would require fewer changes than my other idea.
The second implementation would be identical to the first, except that the output would not be divided by the sum of spoil weights. This would produce a number > 1, that when applied to spoilable products, would increase the spoil time instead of decreasing it. So, taking the yumako mash -> nutrients recipe, if the spoil_weight of yumako mash was set to 1.5, the output nutrients would have 150% the spoilage time of the input (capped to 100%). 20% spoil time mash would make 30% spoil time nutrients, 50% -> 75%, 80% -> 100%


ItemProductPrototype::percent_spoiled > 1

I only have one implementation idea here. If the percent_spoiled is > 1, the spoil time of the output would increase relative to the input (again capped to 100%). Taking the mash -> nutrients recipe from before, if the output nutrients had percent_spoiled set to 1.5 the same result would occur. 20% spoil time mash would make 30% spoil time nutrients, 50% -> 75%, 80% -> 100%

Why?

Primarially, I want to make recipes to "recharge" spoilable items. It would also be nice to create a durability-like system where items with insanely high spoil times are consumed 1% at a time in recipes, then "recharged" 5% at a time with other recipes, so if you let the item fully spoil you have to do more work but getting it "recharged" is much easier. I can also see this being used for refrigerator type mods that extend spoil time, or some interesting calculations surrounding nuclear decay.

[boskid]

I am not convinced by either of the suggestions.

1/ ItemIngredientPrototype::spoil_weight > 1
From a technical point of view, there are absolutely no obstacles to allowing this, but there are also no benefits of having this. When ingredients are consumed a crafting machine computes aggregate "spoil percent" value of ingredients consumed (this value is in range [0, 1]) using weights of individual ingredients but this value is then rescaled by a total weight of all ingredients. Changing spoil_weight from 1 to 2 has the same effect as changing spoil_weight of other ingredients from 1 to 0.5 since the final division by sum will bring the spoil percent back into [0, 1] range. Having spoil_weight unbounded would open a possibility of modders saying "my ingredient is important it will get a spoil_weight of 1000000" and then other mod saying "but my ingredient is importanter! 1000000000!" which is counter productive and goes into various corners of floating point math accuracy. Because of that i do not believe lifting this restriction has any benefits.

2/ ItemProductPrototype::percent_spoiled > 1
There are also no obstacles to allow this, also no benefits of having this. From my understanding of your examples, you assumed that percent_spoiled is multiplicative with spoil percent of ingredients which its not. Those two values are additive (if ingredients were 10% spoiled and product has percent_spoiled = 0.5 (50%) then products will be 60% spoiled) and they are clamped at 100%. That means if a value of percent_spoiled greater than 1 was ever provided, it would fundamentally work exactly the same as percent_spoiled of 1 which gives no benefits to anything.

[protocol_1903]

1/ ItemIngredientPrototype::spoil_weight > 1
From a technical point of view, there are absolutely no obstacles to allowing this, but there are also no benefits of having this. When ingredients are consumed a crafting machine computes aggregate "spoil percent" value of ingredients consumed (this value is in range [0, 1]) using weights of individual ingredients but this value is then rescaled by a total weight of all ingredients. Changing spoil_weight from 1 to 2 has the same effect as changing spoil_weight of other ingredients from 1 to 0.5 since the final division by sum will bring the spoil percent back into [0, 1] range. Having spoil_weight unbounded would open a possibility of modders saying "my ingredient is important it will get a spoil_weight of 1000000" and then other mod saying "but my ingredient is importanter! 1000000000!" which is counter productive and goes into various corners of floating point math accuracy. Because of that i do not believe lifting this restriction has any benefits.

That makes sense, I hadn't thought about the floating point accuracy.

2/ ItemProductPrototype::percent_spoiled > 1
There are also no obstacles to allow this, also no benefits of having this. From my understanding of your examples, you assumed that percent_spoiled is multiplicative with spoil percent of ingredients which its not. Those two values are additive (if ingredients were 10% spoiled and product has percent_spoiled = 0.5 (50%) then products will be 60% spoiled) and they are clamped at 100%. That means if a value of percent_spoiled greater than 1 was ever provided, it would fundamentally work exactly the same as percent_spoiled of 1 which gives no benefits to anything.

Interesting. Just to make sure I understand, are you saying that 10%+50%=60% spoil time remaining or 10%+50%=60% already spoiled with 40% time remaining? In either case, noting this "addition" in the docs would be appreciated. You were correct, I was under the assumption it was multiplicative.

[boskid]

Higher spoilage means lower freshness. 10% spoiled (from consumed item ingredients) + 50% spoiled (from product prototype) = 60% spoiled product. In other words, if you give ingredients that are 90% fresh, and product prototype says product is 50% fresh, you will get item that is 40% fresh.

[protocol_1903]

I see, my termonology and understanding was bad. In that case, could percent_spoiled be allowed < 0 such that it would add freshness to the product, i.e. decaying later?