[Rseding91] [2.0.11] Assembling machine trash slots function as infinite storage

[lvl19]

Assembling machines have unlimited number of trash slots. Arguably a balancing issue and not a bug.

1. What did you do?
Set assembling machine recipe to e.g. iron gears via circuit network. Insert iron plates and wait for the machine to craft some gears, leaving the gears in the machine. Unset the recipe via circuit network; output goes into trash slots. Sometimes there may be iron plates in the trash slots; take those out using a filtered inserter. Repeat.
2. What happened?
Assembling machine fills with iron gears seemingly without a limit.
3. What did you expect to happen instead?
I expected there to be some kind of limit or prevention. E.g. in some other setups I tried, the assembling machine refused to change recipes, or items were deleted instead.
4. Does it happen always, once, or sometimes?
Using the described setup always works.

Savefile demonstrating the method attached.

Related:
-The infinite storage can be accessed for any item manually, by placing items directly to the hand of an inserter.
-Setting and resetting the recipe manually using copy-paste (undo/redo after first time for convenience) also works for input items, but only when character is out of range of the machine. If the character is in range the items are deleted instead, which I don't know if it's intended or not.

[Rseding91]

Thanks for the report. This is now fixed for the next release.

[8igby]

Did this fix cause assemblers to empty their inventory no matter what upon recipe change? A week ago I was able to get an assembler to change between recipes and retain input that would be useful for the next recipe, for instance going from miner to radar. Now it seems inventory gets emptied even when it should be able to immediately start the next recipe.

[Overshot8839]

I am also seeing this change in behaviour. Previously (<= 2.0.11) if the recipes shared input ingredients these weren't shifted to trash on recipe change which was very nice.

Two nice examples which don't work as expected any more:

1) Having a single assembler which could make all types of level one module and switch speed/prod/efficiency/quality using circuit conditions. The control was reading contents of an output chest and a constant combinator with 1 of each type -> a selector combinator in sort ascending -> set recipe in the assembler

2) Using a single assembler to create pipes and gears for engine units controlled by some logic with deciders on the current contents of the engine assembler

Each of these stopped working on the update to 2.0.12 as the input ingredients I think are moved to trash on all recipe changes? So the green/red circuits or iron plates now end up in trash and clog the assembler on every change. Is it possible to revert this behaviour and avoid the original infinite trash size issue in the original post?

[nzer]

Yes, this change appears to cause assemblers to stop working until their trash slots are emptied, which destroys the throughput of most smart assembler designs. If that is what's happening, crafting should probably only stop once the number of items in the trash slots exceeds a certain threshold, rather than stopping when there are any at all.

[Rseding91]

The changes done here were intended and addressed other bug reports we've gotten about confusion with inserters not emptying the trash inventory over the output inventory. The throughput being reduced is a side effect which was deemed acceptable. If throughput is your goal, just make a dedicated machine for the recipe. If you're using set-recipe then throughput is not your main goal and instead you want to make some special/complex setups - which still function.

[nzer]

Respectfully, taking such a hard line stance feels pretty dismissive to all the players who were excited to use the Set Recipe function and have spent hours designing generic assemblers. It really is not your place to assume what people do or don't hold as goals for their designs. I know I at least did not take significantly reduced throughput as a given when using this feature, and I'm not super keen on being told, in essence, that it's okay for the time I've spent on my designs so far to be wasted because the developers don't think the use case I'm targeting is valid enough to not be inadvertently broken by a bug fix.

If this is just a side effect and not an intended nerf to generic assembler designs, please consider other solutions that solve the problem without harming existing functionality.

[nzer]

Like, giving the trash slots a maximum capacity that halts the machine when reached would solve the original problem, and that's how all the rest of the slots already work. Allowing the recipe to be set but not begin crafting until the trash slots are empty would also work, and would at least allow the ingredient slots to start filling while the trash slots are being emptied. Or allowing the recipe to begin crafting but halt at 100% until the trash slots are empty.

I don't have access to the code obviously, so I'm shooting blind here. But I have to imagine there are other solutions.

[Rseding91]

It's possible one of the other developers would like to make additional changes but there are no guarantees. The confusion and reports around the old behavior viewtopic.php?f=23&t=117746 viewtopic.php?f=47&t=117892 have to also be taken into account with any potential additional changes.

It's also possible the behavior stays as it is. Given it didn't exist 9 days ago it still offers options and features that were not a thing pre 2.0.

[nzer]

If I'm understanding those reports correctly, the underlying cause is that the restriction that trash slots be emptied before inserters can pull from the output slots was not clear to the reporters. The machines halting is working as intended, because the players are not properly clearing the trash slots, and they would still halt even with the new behavior in 2.0.12.

I don't think preventing the recipe from being set while the trash slots have items in them actually addresses that confusion. It's still unintuitive behavior, you're just swapping "why is the inserter waiting on source items when the item is right there in the machine?" for "why is the recipe not being set even though the combinator is outputting the correct signal?" Both will look like bugs to players who aren't already familiar with the restriction.

What wouldn't look like a bug is enforcing a maximum capacity on trash slots, because a machine halting due to a full output slot is already part of the game's design language. If the reporters of those two not-bugs had opened the machine and seen the trash slot highlighted, they likely would have understood the problem immediately. Doing this would also prevent infinite storage glitches without needing to block inserters from accessing the output slot, and unlike preventing the recipe from being set it would not reduce throughput for generic assemblers.

[zig1000]

Just adding a +1 to pretty please choose a more throughput-friendly solution to this, I measured an over 1.5x slowdown on my liquids + intermediates smart assembler which was really crushing after having spent days optimizing it by the same amount.

[Overshot8839]

Thanks for the quick response and if it’s intended behaviour then I guess just a new design challenge!

Just to clarify the thing which would be very nice to have (that was working <=2.0.11) is that if you switch between recipes with the same input ingredients, e.g. speed mod 1 -> prod mod 1, then the input ingredients didn’t move to trash but as stayed in the input slots. With the changes (in the module example) the green and red circuits get dumped to trash so you additionally have to pull them out and merge them back onto the belt to be reinserted on recipe change which is manageable but no where near as elegant.

This is separate from the recipes not being set while trash is full (mentioned by nzer) but I think might be a side effect of that change. It is also not (for me) a question of throughput but needing to add in a loop to move ingredients from the trash back to the input even if they are used in both recipes.

As always huge thanks for an amazing game and all the work being done on it!

[DanielJH]

Just wanted to +1 the idea that items in the assembler only get moved to the trash slots if they are actually trash, I.e. not used by the new recipe. It was really cool to make little setups that used one assembler to craft all four of the logistics chests, for example.

[8igby]

A solution to the mall throughput issue, if the current behaviour stays, is to make more than one item at a time. If you make 20, (or 10, or 100) somethings before changing recipe, you drastically reduce the amount of downtime and trash ingredients to deal with. Requires more logic circuits though, but I'm already up to 10ish(doing it pre blue science), this will probably be doable without to much extra logic in my case.

Still, I'd much rather have the assembler be able to reuse ingredients in to the next recipe, but as we have infinite possibilities with our logic, anything is possible(if you ignore setup time in the circuitry).

[zig1000]

Note: Created dedicated topic re: throughput in viewtopic.php?t=118708, since this one's a resolved bug.

[Scyth3]

Hey there seems to be a regression.

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.

Attached Demo save

[Scyth3]

Sorry, missed the last comment of moving the conversation to another post. I'll follow up there.