Recycler (toggle) to output belt stacks only

[husnikadam]

I keep having troughput issues with recylers outputing items on belts since they keep wasting belt troughput by outputing not full item stack heights (less then 4 items per belt tile). I want my belts to be full, to allow me to use proper ratios, which is hard to impossible with current output logic.

My suggestion would be to either add a toggle to recycler to output items on belts only once it got a full belt stack of the items (just like the big mining drills do), or to change the default behavior (without a toggle). If there would be less than max belt stack height of each item, it would wait in the recycler's output slots.

With quality and recycling scrap, this would create an issue of insufficient output slots and clogging the machines, as the recycler would need up to 60 output slots for each item waiting to reach a count of 4. The solution would be to use dynamic output slots count, just as any crafting machine has its own dynamic dump inventory https://factorio.com/blog/post/fff-394

Is this request reasonable? I feel like there are no issues with this new logic, which couldn't be easily resolved and we could finally have full belts

[Kyralessa]

You can do this yourself with a chest, combinator, and stack inserter per recycler. As I recall it's something like this:

1. Have each recycler output into a steel chest.
2. With an arithmetic combinator, do an each operation on the chest contents, taking items with count ≥ 16.
3. Set a stack inserter filter from the combinator output.

You can lower the threshold and the stack inserter limit to 12 or 8 or 4 if you like, to get more frequent output.

If you're using quality, there are 5 quality levels, and the recycler outputs 12 items from scrap, so then you'll need to output to uncommon steel chests (62 slots) to be sure of fitting everything.

[husnikadam]

You can do this yourself with a chest, combinator, and stack inserter per recycler.

Yes, that is what I do to every recycler and it is very tedious once you implement it across thousands of them. I also have concerns about performance of thousands of individual circuit networks. And finally it takes a lot of space and looks ugly. A native function would be way more convenient and I believe a lot of people would benefit from it

[Kyralessa]

The recycler only has 12 internal slots.

This change would require it to have quite a lot of internal slots.

Just to hold the various scrap/quality output would take 60 slots.

If you're also feeding non-scrap items back into the recyclers to break them down further, now you're talking about...no idea how many, but a truly ridiculous number of internal slots.

(I mentioned uncommon chests, but I'm actually using epic steel chests to hold the combination of scrap/quality output and secondary recycled output.)

[worph]

A native function would be way more convenient and I believe a lot of people would benefit from it

There is a fine line here.
"Can't wait to get home and play the game"
"Game is programmed in such a way that is plays itself."


I personally really enjoyed finding this solution myself. If there were a native solution, you had just robbed me of some friction that can eventually produce dopamine and proudness through creativity and intelligence.
On the other hand I love many QOL features similar to this.


The more appropriate question is: Would anyone ever turn such a feature off?
And even further: Should the recycler just function that way on itself all the time?
I think compared to every other assembler type building it would be weird for one of them, especially something with as little philosophical sophistication as something that crushes trash, to keep stock and only output in groups of items. No other machine does this and you would least except the recycler to be the one to do it.

If you don't like banks of recyclers hooked up to circuits and chests, try using a stacker module.
Route all items through filtered splitters and only put the one chest and two stack inserters down for every N recyclers.


But I really don't think this functionality should be the default.
I would even go further and argue: It would be more factorioesque if recyclers (and miners) never output stacks ever to begin with. That functionality should be limited to the one item the grants it: Stack inserters.

Not sure if I really believe the latter point, but sometimes having stacked items and sometimes not seems more egregious than never having stacks, IMHO.

[Kyralessa]

I think compared to every other assembler type building it would be weird for one of them, especially something with as little philosophical sophistication as something that crushes trash, to keep stock and only output in groups of items. No other machine does this and you would least except the recycler to be the one to do it.

To be fair, the big mining drill outputs ore in stacks. So there is some precedent for a machine doing it.

[husnikadam]

To be fair, the big mining drill outputs ore in stacks. So there is some precedent for a machine doing it.

Even recyclers themselves are doing it if they have more than 1 of the same item. It is the inconsistency that is annoying which comes from the recyle probabilities. There are times when multiple recycled results roll and there is a full stack outputed on a belt and there are times when only a single recycle result rolls and there is a singular item on the belt wasting the troughput (along making the belt with different stack heights look ugly)

If you're also feeding non-scrap items back into the recyclers to break them down further, now you're talking about...no idea how many, but a truly ridiculous number of internal slots.

That is a valid point. One solution could be to just let dynamic output/dump slots count baloon similarly as in this exploit (image bellow, source reddit). Or there could be a compromise and set a maximum output slots count and if it were to overfill it would inevitibly output non full stack of items on a belt. Or the machine could just stop.

If the requested feature was a mere toggle, it wouldn't hurt any players which are fine with the current behavior.

07-02-2026, 15-07-30.png (927.49 KiB) Viewed 118 times