Stacking option for filtered splitter

[mattogm]

TL;DR

Where a splitter has a filter applied, provide an option to tell the filtered side of the output to stack items up to the current level of belt stacking research.

What?

Add a "Stack Filtered Output" option to splitters that is linked to the Filter option. The "Stack Filtered Output" option is only active when a filter is applied and has no effect otherwise. This option would be limited to the current belt stacking size, so would have no effect until the relevant research had been done.

When the "Stack Filtered Output" option is turned off, splitters behave as they currently do, passing items straight though at whatever stack size they currently have.

When the "Stack Filtered Output" option is turned on, the filtered output of the splitter would behave somewhat like a stack inserter and only output full stacks of the item being filtered for. If too few items enter the splitter to form a full stack, they will be held inside the splitter until sufficient items arrive to make a full stack. As with other belt mechanics, this would operate on a per-lane basis, so items would be held and released per lane. Items would not be combined between lanes to achieve a full stack.

The non-filtered output of the splitter would not be affected by this option and would behave as it currently does, passing through items at whatever stack size they currently have.

Changes to the splitter settings (e.g. changing the filtered item type) would be handled similarly to how the stack inserter handles them i.e. releasing any partial stacks that no longer match the filter.

Why?

Currently, the only way to achieve stacking on belts is to use stack inserters when adding items to the belt. Tasks like combining multiple unstacked belts into a single stacked belt require a number of stack inserters to effectively unload and re-load the belts. Some way of stacking belts in a more in-line way would be useful, and more efficient than using inserters to unload and re-load the belts.

Limiting this option to the filtered side of a splitter gets around the potential for causing jamming of the belt if multiple item types are present. Initially I was going to propose a simple "Belt Stacker" item that would sit on a single belt and just stack items as they passed through it. However, I then realised this would easily jam if there were more than one item type on the belt (e.g. sushi belts), similar to how stack inserters can jam when trying to load multiple item types into the same machine. By definition, the filtered side of a splitter will only ever be outputting one item type, so while it might hold up items until it can form a full stack, it would never become completely stuck.

This would allow a single-item belt to be fully stacked at full belt speed using a single splitter, instead of the current solution requiring multiple belts and stack inserters. While it would still potentially hold up 1-3 items per lane waiting for enough to make a full stack, this is much less than would be held up in all the stack inserter hands for the current solution. This could be particularly effective on Gleba where using stack inserters to output spoilable items from individual machines (e.g Agricultural Towers) can lead to items waiting a significant amount of time in the hand of a stack inserter, wasting spoilage time. Consolidating the output of multiple machines onto an unstacked belt and then putting it through this filtered stacking splitter would mean new items are arriving much more frequently so the potential time items would be spent held up waiting to make a full stack would be much lower, and negligible for full input belts.

A single filtered splitter could take 2 unstacked single-item belts in and through stacking output all the items from both input belts onto the filtered output (and the output belt would still only be half-full with full stacking research). Two of these, with a third unfiltered splitter to merge the two filtered outputs would then provide a neat and efficient way to combine 4 unstacked belts into a single fully stacked belt.

Sushi belts could be stacked using a series of filtered stacking splitters one after the other (one for each item type) - with both outputs of the first filtered splitter fed into the second, the second splitter would simultaneously stack the second item type while merging the stacked first item back onto the sushi belt. You'd then end it with a final unfiltered splitter to merge the final item back into the sushi belt.

[Muche]

A single filtered splitter could take 2 unstacked single-item belts in and through stacking output all the items from both input belts onto the filtered output (and the output belt would still only be half-full with full stacking research). Two of these, with a third unfiltered splitter to merge the two filtered outputs would then provide a neat and efficient way to combine 4 unstacked belts into a single fully stacked belt.

I'd say this a reason to not implement it.
It makes stacking too easy and stack inserters obsolete.

[mattogm]

Having splitters able to stack does lower the barrier to entry to start using stacking - I could see people using them initially to consolidate the output of existing smelter blocks into fewer belts to squeeze more down their main bus footprint without a complete re-tooling of the entire production chain. But you're still going to want to go back and do that re-tooling later for all the other benefits stack inserters give, especially if you're upgrading to other Space-Age-specific machines at the same time. So while this is a lower barrier to entry, to me it feels consistent with the general progression of Factorio in introducing you to a new capability, then letting you go further down the rabbit hole.

Stack inserters will still be better than a stacking splitter in many scenarios:

• Inserting to the belt pre-stacked gives the stack inserter significantly higher throughput in the chest-to-belt scenario compared to the bulk inserter because it has to wait for fewer slots on the belt to pass under it to empty the hand
• The larger hand size further gives it a higher throughput than the bulk inserter in all scenarios
• If you're running 4 belts and then merging them, that's 4 times as much belt you've got to use, and find space to fit through the build until it gets to the stacking splitters. Alternatively if you use one belt and a stacking splitter after each bulk inserter adding to the belt you're not going to achieve a saturated stacked belt.
• Its "self clocking" behaviour alone (i.e. waiting for a full hand before swinging) is desirable in some UPS optimisation scenarios

So I don't think the addition of a stacking splitter would result in people no longer using stack inserters in the scenarios where they are already working well.

The main place I see a stacking splitter like this being the best option is in scenarios where the behaviour of the stack inserter causes problems - specifically the examples of Gleba with spoilage issues and Fulgora with its mandatory sushi belts. While I'm aware people have been coming up with circuit network tricks to make the stack inserter work better in these scenarios, it's doesn't feel like a great solution, and adding the stacking splitter would open up a wider range of design choices for dealing with these challenges.