Stack Inserter Drop Stack Onto Belts

[Deadly-Bagel]

To put it simply, have Stack Inserters drop the whole stack onto a belt (over-compressing as with the new belt compression mechanics) - this would allow the Inserter to make a full swing, picking up a new stack, and be ready with a new stack before the previous stack is cleared. Additionally, when picking up from a belt allow it to pull from both lanes simultaneously (if the same resource), bringing the grab time from a blue belt down to a flat 0.3s

The whole bot vs belts thing is blown a bit out of proportion I think but we seem to all agree that belts could do with a QoL improvement to make them more feasible in high-end factories, and the main trouble with belts is their response time. A Stack Inserter will pick up and drop off 12 items instantly between inventories but for belts it has to wait for the items to pass - a blue belt moves 20 items per second per lane, so you're waiting 0.6 seconds for the belt to catch up which more than triples the round-time of a Stack Inserter if either source or destination is a belt (when picking up from belts I think it's slightly faster, maybe 0.5s).

This behaviour would allow 2 Stack Inserters to compress a belt (currently need at least 5) which would drastically simplify unloading from trains, and also would allow belts to keep up with an Assembler using 4x Productivity modules and 8x Speed Beacons without needing to transfer from belt to chest to Assembler.

I initially thought about if Stack Inserters could drop to both lanes simultaneously, but for consistency that would probably need to be an option and stack size would need to be increased to 15 for two of them to compress a blue belt.

[bobucles]

You mean that the items get scrunched up on the belt and then decompress down to normal size? That would give inserters a faster interaction with belts, but it also looks pretty ugly. It also changes inserter priority where the first inserter to touch down will always force its items into the belt.

[dragontamer5788]

I think this idea has been discussed in FFF: https://www.factorio.com/blog/post/fff-225

New tier of belt which would be able to stack items.

Honestly, there are a ton of belt-buffs that were discussed in that post, and a lot of them sound good. Its hard for me to figure out which one is best. Clearly, the best solution is for us to make mods and play around with prototypes, and then decide which one is best.

The simplest solution is probably to just make an 8x fast belt (blue belts are 3x fast). It wouldn't take much coding. Maybe 10x speed is the ideal point to be competitive with bots (bots are currently estimated to be 2x better than blue belts, but some additional bonus should be added because belts are less convenient than bots).

Personally speaking, I like "Packed items like pallets/containers" as the best solution. There's no need to have belts claim "superiority" in all cases. If you make belts superior for mid-range travel, and make bots superior for "last mile" delivery, then the ideal Factorio base would require all infrastructure in the game to be used for maximum efficiency. That seems to be the most ideal balance for the game: each item is being used for its niche where it is best. Belts for "packed pallet" movement, bots for "last mile", and trains for large bulk deliveries.

It seems like the devs were leaning more heavily into "stack belt" idea however, which would suggest that they maybe prefer belt-based superiority, even in last-mile.

[Deadly-Bagel]

Yeah I said belts could just do with a QoL improvement, they don't really need a buff. I don't think faster belts will really help anything, it would just be another tier to sink resources into and spend hours upgrading your factory to, not to mention you would need to use even more Stack Inserters to fully compress.

You mean that the items get scrunched up on the belt and then decompress down to normal size? That would give inserters a faster interaction with belts, but it also looks pretty ugly. It also changes inserter priority where the first inserter to touch down will always force its items into the belt.

It would only drop items if there's a gap, as with current Inserter logic, though with this method a single Stack Inserter would never leave a gap on its lane. For consistency I suppose this logic would apply to other Inserters but I don't really see why it would be a problem. Ugly? Pff, all you see is a solid compressed belt, most of the time with an Inserter hanging over each squashed bit so you don't even see that. What's the problem?

Actually Inserter priority won't change. if 2.5 Assemblers are required to compress a belt then the 3rd Assembler will always produce at 50% capacity and the belt is compressed from thereon, regardless of belt loading method. If the gap between Assemblers was small enough and the Assemblers were working fast enough there -may- be some fringe cases but it would take pretty absurd numbers to get that, and even then it would only be a slight shift in priority.

Personally I don't like stack belts or pallets. Improving the throughput of belts isn't the goal, they move plenty of items already, so stack belts aren't the way to go. What's the difference between that and a faster belt anyway, other than that you'll end up with more "useless" items stuck on the bus? Pallets idea is similar, and while it would improve loading time I guess it would also be a buff for robots too so defeats the object. If you want to make it some automatic belt-only thing then it's identical to the stack belt idea, and what's the difference between that and faster belts?

[Zavian]

Personally I would rather see the devs go with something like viewtopic.php?f=190&t=57264 . If the devs did a vanilla implementation of that then you could remove the beltboxes, and stack inserters could gain an option to deposit stacks on belts, and to transparently decompress stacks to items when picking items up.

[dood]

Personally I would rather see the devs go with something like viewtopic.php?f=190&t=57264 . If the devs did a vanilla implementation of that then you could remove the beltboxes, and stack inserters could gain an option to deposit stacks on belts, and to transparently decompress stacks to items when picking items up.

It's not that simple, the "stacks" are not actual stacks of items but separate products altogether.
As such, stack inserters can't just drop 10, 8, 1, 5, 2 items as a stack since the "stacked item" entity consists of a fixed number of items.

If they allowed for variable stack sizes, apart from looking horrible, I'm pretty sure it would also undo all those neat belt optimizations with non-uniform stacks of varying sizes.

[bobucles]

Variable stack size looks horrible

It looks pretty nice to me.

item stacking.png (682.72 KiB) Viewed 7895 times

[Deadlock989]

Variable stack size looks horrible

It looks pretty nice to me.

It's easy - probably literally easiest - with plates.

Try it with engines or uranium-238.

[Deadly-Bagel]

bobucles, that is not the suggestion I'm making. See my above comments on "stack belts".

The stack should stay in place on the belt and the belt would move items out from under it, exactly the same as when an Inserter drops an item into a too-small gap, but instead of 1 item at a time it would drop 12 at once.

[dragontamer5788]

bobucles, that is not the suggestion I'm making. See my above comments on "stack belts".

The stack should stay in place on the belt and the belt would move items out from under it, exactly the same as when an Inserter drops an item into a too-small gap, but instead of 1 item at a time it would drop 12 at once.

I've reread the topic, and I think its a bit confusing because the Devs have already defined "stack belts", which are completely different than your suggestion. Your suggestion is to remove the "innate nerf" of inserter->belt vs inserter->chest. True, its technically a belt-buff, but it isn't really a major change at all. In short, you want the inserter to not be "tied up" waiting for the stack to decompress whenever it drops onto a belt. Under your scheme, the belt probably would be tied up. I have some concerns about how it would work with belt-"priority", but I think its a reasonable suggestion overall.

In short: this topic is focused on the inserter->belt slowdown.

[bobucles]

I'm not entirely sure how useful this would really be. Once a belt maxes out, your inserter speed stops being important. You can't make a belt faster by cramming more inserters into it. Any simple belt design can already let 4 stack inserters flood a blue belt without any gaps.

saturated unloading station.jpg (544.66 KiB) Viewed 7839 times

Inserters are actually extremely efficient when they are unloading up to 3 items at a time. Compare the transfer rates on the wiki for upgraded fast inserters

Code: Select all

Fast inserter
Chest to chest: 6.93
Chest to belt: 5.63

That is 81% of a direct chest transfer rate, which is very competitive. Transfer rates slow down when the inserter is waiting for the belt:

Code: Select all

Stack inserter
Chest to chest: 27.7
Chest to belt: 12.2

The first 3 items move quickly enough, but now it has to wait 9 more slots to unload the rest. That wait time makes it only work at 44% speed attempting to saturate a belt. You can work around that without much difficulty thanks to the devs making it very easy to compress belts.

[dragontamer5788]

Code: Select all

Stack inserter
Chest to chest: 27.7
Chest to belt: 12.2

The first 3 items move quickly enough, but now it has to wait 9 more slots to unload the rest. That wait time makes it only work at 44% speed attempting to saturate a belt. You can work around that without much difficulty thanks to the devs making it very easy to compress belts.

Well there we go. It means 2-stack inserters can max out a blue-belt (under Chest-to-Chest x2 == 55.4 items/sec, way more than the 40-item/sec a belt can handle), but under current conditions, you require 4-inserters instead.

So right there, if this "stack inserter drops stack on belts" were implemented, you'd cut the number of inserters-per-belt in half. It would means that one-sided train stations would all go ~2.27x faster. Etc. etc. It'd be a huge QoL buff to belts.

[bobucles]

It'd be a huge QoL buff to belts.

I mean. Not really? You're taking a pretty easy task (filling a belt) and making it even easier. That's all fine and dandy but assemblers are hardly plagued by output issues. The standard recipe takes a large number of input ingredients and generates a tiny amount of output products. This idea lets them output products faster than ever, but it does nothing to change the Belt => Inserter input speed that they crave most. If assemblers can't get enough items into their belly then you're still stuck at square 1.

Same idea with trains. It doesn't make trains load any faster because the choke point is waiting for belt input. It will let trains unload faster since belt saturating takes up less space. I never had any real issues dumping a lot of belts out of a train though. You get 12 inserters per wagon, after all.

Overall it's a pretty tiny QoL at best.

Try it with engines or uranium-238.

The solution to avoid stacking items is very easy: Don't use stack inserters! I see no real reason to remove the option if players really want it, but a vast majority of recipes simply don't call for stack output. There are even situations where forcing stack output can hurt players such as if they're using a long belt line that buffers too many high tech resources. Use a normal inserter or long inserters to keep vanilla behavior. Use stack inserters to get the increased belt capacity. It's not exactly rocket science, though it is probably off topic a bit.

Stacking items on belts WILL increase item input speed, which is exactly what assemblers crave. For example if the stack size was 4 tall, then a stack inserter only needs to grab 3 sets of items to fill up. Three grabs per swing is pretty much identical to how a fast inserter does 3 grabs per swing, and we have hard numbers for that. Those ordinary inserters on ordinary belts are around 80% efficient, compared to stack inserters getting around 45% on ordinary belts. Item stacking will increase belt/inserter input AND output speed in very significant ways.

[Deadlock989]

Try it with engines or uranium-238.

The solution to avoid stacking items is very easy: Don't use stack inserters! ...

I meant graphically. It's not at easy as it seems. Not all the icons lend themselves well to being stacked in tottering, unrealistic piles. I found out the hard way.

[dragontamer5788]

It'd be a huge QoL buff to belts.

I mean. Not really? You're taking a pretty easy task (filling a belt) and making it even easier. That's all fine and dandy but assemblers are hardly plagued by output issues. The standard recipe takes a large number of input ingredients and generates a tiny amount of output products. This idea lets them output products faster than ever, but it does nothing to change the Belt => Inserter input speed that they crave most. If assemblers can't get enough items into their belly then you're still stuck at square 1.

Same idea with trains. It doesn't make trains load any faster because the choke point is waiting for belt input. It will let trains unload faster since belt saturating takes up less space. I never had any real issues dumping a lot of belts out of a train though. You get 12 inserters per wagon, after all.

Overall it's a pretty tiny QoL at best.

You have a point for assembly machines, but I still suggest that this is a big deal for train stations.

Currently, a 12x inserter wagon unloader can handle 3.7 blue-belts of output. With the buff suggested in this topic, it would instead handle 6 blue-belts of output. That's 60% more train throughput than before. Well, for belts anyway. (Bots always had the "max speed" unloader because wagon->chest mechanics are way faster)

[Deadly-Bagel]

That's all fine and dandy but assemblers are hardly plagued by output issues. The standard recipe takes a large number of input ingredients and generates a tiny amount of output products.

True, though dropping items onto belt is not necessarily train>belt but more chest>belt which has a few additional uses.

However, a problem that does plague Assemblers is when you have 6+ Speed Beacons and Productivity modules the Assembler will run out of materials faster than the Stack Inserter can respond. It's not that it's not fast enough, it's that the Assembler runs out of material between asking the Stack Inserter for more and the Inserter actually providing it. If you load from Belt > Chest > Assembler then it works, barely.

That is the reason for the second part of the suggestion to allow Stack Inserters to simultaneously grab from both sides of the belt, it would really improve both response time and throughput from belts.

[bobucles]

However, a problem that does plague Assemblers is when you have 6+ Speed Beacons and Productivity modules the Assembler will run out of materials faster than the Stack Inserter can respond.

Low tech recipes need a tremendous throughput to work and the weakest point is going to break first. Currently stack inserters can grab around 11-14/sec from a belt. If you tap them at their hardest that means your belt dries out after 4 stack inserters. If you buff stack inserters the breaking point simply shifts to belts. So if inserters grab even harder it only means the belt runs dry after the first 2 or 3 inserters.

A 6+ speed beacon build can easily fit 2 belts and 2 stack inserters per machine. The very first thing to break is that the belt reaches capacity after the first handful of wire or GC assemblers. Their demand is simply higher than anything a belt can handle. Heck, it's easy to reach belt capacity on GCs without even using a single speed module! Just how hungry are GCs? They're a low tier resource that still pumps through enough items to be a B-rank for productivity modules. That's crazy.

The problem with belt transfer speed has always been a package deal. Inserters are slow because the belts are slow. The belts are slow because the recipes are fast. The recipes are fast because everything needs them. Not much can be done about feeding a beacon build unless the end point becomes less demanding or the whole supply chain is strong enough to meet it.

[Deadly-Bagel]

If belt capacity is the problem, bring more belts? The simplest solution is to have belt lines outside and away from the assemblers, split and UG belt them in. It's harder to add more inserters as there is only a limited amount of space around each Assembler.

[Deadly-Bagel]

That's all fine and dandy but assemblers are hardly plagued by output issues. The standard recipe takes a large number of input ingredients and generates a tiny amount of output products.

Actually I have just run into this problem, feeding Copper Wire onto a belt for beaconed Advanced Circuits. 4 Prod modules and only 3 speed beacons on those Assemblers, a Stack Inserter onto a belt cannot keep up with the output.

There's not many recipes that you're likely to run into problems with, mainly Copper Wire for the likes of science and Advanced Circuits. Actually plastic is another likely one.