[2.0.12] Hand crafting Yumako processing recipe results in unexpected stack spoilage value (MR)

[mordof]

I suspect this is a bug anyway, as this seems kind of bizarre to me.

If I have 100 Yumako in my inventory, and then queue them all up to hand-craft them all using Yumako processing (Recipe), all of the output Yumako mash share the same spoilage timer, as well as (what I think might be the biggest concern) having turned into spoilage.

Normally what I've noticed from other recipes that create a spoilable item, is it helps refresh the spoilage timer each time a new item gets crafted and added to a stack. This doesn't happen at all with the Yumako mash.

e.g. When the first stack of 100 Yumako mash is finished entering the inventory (with the timer consistently counting down), a second stack starts. This second stack already shares the first stack's spoilage timer (I would expect this to be getting it's spoilage timer from the Yumako being processed, not the other stack, as the Yumako being processed can still be just about full timer but still exhibit this behavior).

The weirdest part that then happens because of this, is once the previous stacks of Yumako mash turn into spoilage. All subsequent recipe results from that stack of crafted Yumako turn IMMEDIATELY into spoilage (even when the Yumako itself is still close to completely fresh).

In order to stop this from happening, the entire queued Yumako processing must be cancelled, and started again, in order to resume receiving Yumako mash.

If there's any further information I can provide here, or steps to recreate further, please let me know.

Side note:
=========
I also have no idea if this means the seeds won't be created anymore when it's turning immediately into spoilage, but my guess is it likely wouldn't influence seed production - haven't been able to confirm.

[mordof]

Was just hand-processing Jellynuts, and they appear to have the same behavior.

[mordof]

Additional information to add that I just discovered:

If I have, say, 150 of either Yumako or Jellynut processing already queued in hand-crafting (since it applies to both - discovered after original posting), if I wait a little bit and then queue any additional amount of them, adding to the current stack of processing queue, then it increases the spoilage time immediately for new items being made, even though those newly queued items would be at the end of the stack.

From that behavior, I suspect it has to do with a variable being kept in the hand-crafting queue that is determining when it spoils, not when the item itself is finished crafting. Further, that variable is stored as a single instance for the entire hand-crafting stack, and not per item within that stack.

My guess is that, since spoilage is a new feature, the noted behavior above of how hand-crafting items as a stack was likely just tweaked to add the spoilage timer to it, and then copied to the item as it landed in the inventory. I think it makes more sense for the spoilage timer to start as the item is landing in the inventory instead, though I can imagine there may be complications due to item instancing timing that may get in the way there.

This begs the question though:

If I have a long queue of hand-crafting items, and I add a spoilable item to the end of that list (say something that, for the sake of argument, spoiled after 1m), but it took longer than 1 minute to get to that item in the hand-crafting process.... would that item already be spoiled by the time it's crafted? When does the spoilage timer get started for hand-crafted items is really the important question that this raises.

[Muche]

Ref 120019 Yamako Mash not appearing in inventory, 119771 Wrong spoilage calculation from backpack crafting, 122057 Items begin to spoil before they are finished crafting, 120726 Jellynut processing stops creating jelly if creating too much, 122472 Pausing Spoilage, 125860 Biochamber with in-progress pentapod produces nothing at all after spoil time expires, 126498 Handcrafting large amounts of spoilables causes products to spoil immediately.

[Gorb]

This continues to be a problem in version 2.0.39

Quing many Yamako mash, or Jelly via right click spamming can result in newly made mash/jelly instantly becoming spoilage. It appears to base the spoilage timer upon the first item crafted and all subsequent ques share that spoilage timer.

Upon farther testing, it seems that the first stack of mash will increase the freshness with each item added to the stack. Once a 2nd stack is created, that added time to freshness is no longer applied to the stack. When that stack (or first item in the 2nd stack), spoils, the stack spoils and any subsequent craft creates spoilage, no mash is created. This continues even if the newly crafted item, creates a new stack. The 3rd stack crafted by que will go directly to spoilage, no mash will be created.

[Rseding91]

I know what's wrong with this but I don't have a solution for it due to the nature of how hand crafting works in Factorio.

The root issue: the "tick the crafted item(s) should start spoiling" is computed at the very start of a hand-craft request. For example queuing 1000 recipes of the Yumako mash recipe with all ingredients being 92% fresh says "all crafted items should start at 92% fresh, at tick *now*"

Then, 1 second later when the first of the thousand crafts finishes it produces the result, sets it to 92% fresh, and then advances the spoil time by 1 second (the total time to craft so far). This is all well and good - for this first craft.

But now comes the 2nd craft 1 second later (2 total seconds into crafting the 1000 times): When the second of the thousand crafts finishes it produces the result, sets it to 92% fresh, and then advances the spoil time by 2 seconds (the total time since crafting started)

This is where the issue is. Hand crafting consumes all ingredients at the very start of crafting and the logic for computing product spoil %s fails in this case. To complicate things more, you may have intermediate crafting steps that do or don't involve spoilable items which throw off the crafting time even more. The entire hand-crafting system would need to be re-worked to store - but not consume - items for crafting and then 1 recipe at a time convert things between recipes preserving the actual time ingredients got consumed and results got produced through recipes. That is functionally re-writing the hand crafting logic and so far nobody has signed up to do so - and I'm not even sure if it's worth doing.

I'd personally like if we could just disable hand-crafting with spoilable items but I don't think that's possible at this point.

[robot256]

It's effectively partially disabled now, except the message to the user is by spoiling the first large batch they try to hand-process. If there was a hard limit on how many spoilable items you could queue, or some sort of text warning that the result might spoil before you're done crafting then it would look less like a bug.

The other solution, making items not spoil during handcrafting, or retain the longer of the input/output spoilage time until placed in inventory, is a little more cheat-like.

Maybe a note that the clumsy player will crush the fruit if they try to juggle more than a few crafts at a time. Something like that.

[Rseding91]

We talked about this internally and decided that the complexity and potential errors in re-writing the hand crafting logic are not currently worth it to address this issue. For now, we're going to leave this as is. There are a few work-arounds - with the main one being assembling machines that can automate the crafting and will not run into this issue.

[Gorb]

This feels bad as a player. The initial fruit has a 1 hour spoilage time, the new item spoils before it is created. The increased spoilage timer applies to the first stack of items created, not to subsequent stacks. It takes a fair amount of testing to understand what the problem is and why it is happening. What's worse is that no seeds are created in this process so it burns the fruit without replacement options.

If this behavior is going to be kept, players should be notified so they understand what is happening and can take steps to avoid it. At the very least, a message should be displayed when the hand crafted item turns directly into spoilage.

Alternative options would be to stop the players hand crafting when the item created is spoilage. Ideally the hand craft cycle would just reset (aka resubmit the crafting commands), after the first stack of spoilable items are created, because it does work correctly for the first stack.

[eugenekay]

Neat, a recursion problem in real life! A thought occurs: what if Handcrafting is made Simpler to deal with Spoilables, not more complex?

What if the Handcrafting of Spoilable items is restricted to 1 Craft at a time? I think the calculated “Spoil Time” for each item would then be (approximately) correct since it is re-running the calculation each time you add another Craft to the end of the queue, thereby accounting for the intermediate spoilage time on the Ingredients? Canceling items in the middle of the stack might still result in Cached Spoil values being wrong.

A message could even be popped-up for “Craft 5” or “Craft All” actions that “This Product cannot be hand crafted in bulk. Use a Machine to automate it”; guiding Players in the desired direction.

[robot256]

Neat, a recursion problem in real life! A thought occurs: what if Handcrafting is made Simpler to deal with Spoilables, not more complex?

What if the Handcrafting of Spoilable items is restricted to 1 Craft at a time? I think the calculated “Spoil Time” for each item would then be (approximately) correct since it is re-running the calculation each time you add another Craft to the end of the queue, thereby accounting for the intermediate spoilage time on the Ingredients? Canceling items in the middle of the stack might still result in Cached Spoil values being wrong.

A message could even be popped-up for “Craft 5” or “Craft All” actions that “This Product cannot be hand crafted in bulk. Use a Machine to automate it”; guiding Players in the desired direction.

I believe this can be done in a mod, as a way to demonstrate its importance. Either way, we need to move this discussion to a Suggestions thread before they lock it.