Improve 'Set Recipe' throughput/simplicity

[zig1000]

Since viewtopic.php?t=117890 and viewtopic.php?t=118465 included other bug reports (some inaccurate) and were closed, creating this as a dedicated topic on Set Recipe throughput. In particular whether the 2.0.11 -> 2.0.12 performance hit can be recovered without regressing bugs.

Current mechanics:
- Assemblers cannot set recipe while there are items in their trash slots. This means trash emptying and ingredient loading can't be done in parallel.
- When setting a recipe, items go to / stay in trash slots even if they are ingredients of the new recipe.

Subjective arguments:
- Smart malls tend to pay large switching costs and to only have one operative assembler, and any scaling in this number or their versatility (liquids, intermediates) comes with proportionate increases in their size and complexity (e.g. sharing sushi across assemblers).
- So, they already have a huge nerf to their speed and practical viability relative to the effort to use them. Adding an additional nerf to their throughput that regular assemblers (which can load/unload in parallel) don't have is a disproportionate price for their flexibility, and makes it hard to justify using them.
- I'd even argue that they needed a buff, which makes changing the second listed mechanic really appealing. It makes smart assemblers pay a performance price proportional to how 'much' the recipe is changing by. It opens up all sorts of fun design space around deliberately making an assembler only switch between specific subsets of recipes that share items in order to move around on the speed <-> flexibility pareto frontier.
- My painstakingly many-days-optimized design took a 50% slowdown and I'm a salty little gamer about it

Suggestions:
- When a recipe is set, automatically move items already in the assembler into ingredient slots if possible
- Block Set Recipe only when some fixed upper bound on trash slots is exceeded

[ray4ever]

I like your suggestion.
With the current state of implementation my once "smart" assembler is now useless.

[8igby]

This is a good suggestion, that will make a logically controlled mall work reasonably well again. I set my goal of making an early mall with this type, before blue science, that would be fed by a sushi and change recipes after a craft had started. It took a lot more logic than the "meta" one we keep seeing around, but it did work fast when being set up with tasks that didn't have to much of a change of input. This new method just keeps overloading my trash output(sushi into the mall input). Of course, I can kind of mitigate this by making more of one resource at a time(counting Done signals to 10 or 20), but it would be really nice if the assemblers were a bit smarter about trashing inputs.

[nzer]

Just chiming in to say I agree with this, however I think a more appropriate solution would be to allow the recipe to be set, but to block ingredients from being inserted while the trash slots are full, with the inserters displaying "Target full." This is what happens when an assembler's output slot is full, and trash slots are basically just an output slot.

I think your analysis is spot on as well. Smart assemblers already have significantly costs associated with them, to the degree that players are unlikely to want to use them for anything but a mall. There's no real need for them to have inherently reduced throughput on top of that.

[nzer]

In fact, trash slots not behaving the way the output slot does is the whole reason these infinite storage glitches were possible in the first place. When the output slot exceeds a certain amount the assembler blocks inserters from inserting ingredients, but the trash slot previously did not. When the output slot meets or exceeds the stack size of the item in the slot it goes even further and prevents crafts from completing, instead halting at 100%. Applying these restrictions to trash slots as well would be enough to prevent infinite storage glitches, with no need for further restrictions.

[elfstone]

I agree with OP. We made a design where only assemblers with the same ingredient used set recipe, which made it less generic but with a very high throughput. I think the suggested behavior is not just a buff to set recipe, but also allows a greater variety in builds which makes set recipe more interesting.

[Muche]

I would also say that an assembler not showing applicable set recipe while trash slots are filled is misleading, as it conflates incorrectly set recipe (e.g. recipe's technology not researched yet, recipe is exlusive to other surface, no applicable recipe from received signals, no received signals due to general circuit network mishaps; that is, generally permanent issues, requiring player's intervention to fix) with recipe not working (insufficient input/power, full output; that is, temporary issues, requiring no intervention if set up correctly).

[Scyth3]

IMHO I rather have abusable infinite storage like the fixed bug instead of having to make the "set recipe" functionality more complex to use. Honestly I'd consider it a regression.

For example it used to be that the following contraption worked but now gets blocked by trash slots and "no recipe", despite receiving a recipe through the circuit network

Works in 2.0.7 but is instantly blocked in current 2.0.13.

11-01-2024, 14-39-19.png (282.03 KiB) Viewed 759 times

Attached save

[Scyth3]

A potential compromise would be that when "set recipe" sets a recipe it takes into account ingredients currently in the trash slot and automatically moves them to the ingredients slot.

In the previous case, switching the recipe between Rail Signal and Chain Rail Signal should move leftover plates/EC back to the ingredients.

[Scyth3]

It's also related to this post viewtopic.php?f=6&t=117032

Needing to read assembly contents to remove trash while also setting recipe at the same time brings unnecessary complexity

[MrGrim]

Adding my voice to the chorus requesting ingredients re-use when changing recipes be re-added. See viewtopic.php?p=631964#p631964 for an example of a dynamic module blueprint that will become much more complex than it already is if it must constantly fish out circuits.

[naaram]

I totally agree. For me the problem is not about throughput but about simplicity. I do not want every blueprint in Factorio to become a programming excercise. Before I could make an assembler produce multiple things with the same input with just three combinators. Now it has become a two hour designing and tweaking endeavour.

[flexo]

Not that this will change any minds but...

I updated to 2.0 the first day it came out. Couldn't even afford to buy Space Age. The very first thing I did, that I'd been looking forward to since the set recipe feature was announced, was go into editor mode to make a little yellow belt assembler that could make its own gears. Not because it would be some huge game-breaking advantage - just because I thought it would be nice. And to my absolute, unexpected delight, it turned out that the assembler could hold onto a gear or two that it had just finished, switch to yellow belts, and immediately start using them. It would just bop back and forth, making a few gears, making a few belts, with no hiccups. I was in love. I just stared at it for a while, and then finally decided to make a second thing... the same design, but without the decider. Just a yellow belt on a tiny loop, sending out its signal whenever a few gears had accumulated.

I found it beautiful. Truly beautiful. I know different people will have different things in Factorio that make their heart sing. For me, there was the first time I had a dozen trains zipping in and out of my main base, barely needing to slow down to squeeze around each other, and then, there was this.

So it is a huge, HUGE bummer to have that in the game, and then have it just disappear, basically by accident. Because removing it was an easy way to solve some tangentially related problems. It's silly to be sad about this, but I'm sad about it.

[MrGrim]

I'm worried the title of this thread will hide what people are really asking for. Can it be modified?

[Tinyboss]

OP can do it.

Suggestion: "Fixes for throughput reduction when setting recipes via circuit signal"

[zig1000]

I don't think that says anything the title doesn't already convey, but I have put some quotes in to make it clear from more than just the capitalization that this is [Set Recipe] throughput and not Set [recipe throughput].

If you think the ingredients -> trash mechanic is a bug (unclear to me, I know at least the blocking of recipe changing was not accidental), you could make a post in bugs about it. When I made this I wasn't aware that persistent ingredients used to not move to trash.

[Tinyboss]

I thought you were asking for a way to set the recipe throughput to a certain rate. To match rates on consumers.

[zig1000]

Reworded one more time, hopefully it's clear now

[Tinyboss]

Yes, that reads clearly to me!

[Tomeamis]

I'd like to join in on this, even just allowing the common ingredients to stay in the ingredient slot would be a huge improvement and I don't see how it could be abused.