[0.13] Make inserter stack bonus individually configurable

[Cabanur]

To pick up items from the train when blocked inserter got in hand 3 items (so everything will unlock).

There's this other thread where we're talking about being able to read a train's content via circuit network. I think these two ideas work great together.

[MindChanger]

To pick up items from the train when blocked inserter got in hand 3 items (so everything will unlock).

There's this other thread where we're talking about being able to read a train's content via circuit network. I think these two ideas work great together.

Yes, but with this idea implemented we don't need to read what is in wagon

[Cabanur]

Yes, but with this idea implemented we don't need to read what is in wagon

Actually if this was implemented *and* we could read what is in the wagon we could easily keep max stack size until the wagon is almost full, then only on the last stroke reduce the stack size. We'd have the speed bonus of stacks *and* the flexibility to load multiple items with one inserter.

[siggboy]

We'll almost certainly get the capability to read cargo contents of the train from the station in 0.13. IIRC Twinsen has already announced this for the 0.13 cycle in one of the related FFF articles.

Right now we're in the situation where you can ask wooden chests what they contain, but not a train what it has loaded (unless you use SmartTrains); that does not make a lot of sense.

If the train cargo can be queried, then it would be quite easy to make a smart loader that could load at almost full speed to, at worst, (stack size - 2) at full tech; you would let the stack inserter work until fewer than 12 slots are free, and then let a fast inserter load the rest (that might still leave a few slots empty, but it would be a very simple and fast solution). If the stack bonus is actually adjustable, that would allow you to fill those last remaining slots as well (it's what Cabanur wrote).

[MindChanger]

Yes, with reading content it would be doable, but without it there is no problem about it too if we get idea from this thread

[Cabanur]

Yes, with reading content it would be doable, but without it there is no problem about it too if we get idea from this thread

It would be doable, yes, but we would be forced to either always move items one by one, or check if the inserter is stuck and empty the wagon one by one until it can finish loading. So a bit inconvenient.

[MindChanger]

Yes, with reading content it would be doable, but without it there is no problem about it too if we get idea from this thread

It would be doable, yes, but we would be forced to either always move items one by one, or check if the inserter is stuck and empty the wagon one by one until it can finish loading. So a bit inconvenient.

Actually only detect that inserter is stuck and unstuck it with only one inserter's movement (by reading stuck inserter's content type and amount and then setting it for unloading one).

[MeduSalem]

Just curious, in what cases would you really want a inserter limited at 3 stack size when 12 is available?

The stack inserter takes too long to pick up items from the belt, so by the time it dumps them into a level 3 assembler it has already stopped working. The fast inserter needs to move more often but you don't get pauses.

I'm not sure if this should be reported as a bug (stack inserter waking up too late when used with fast assemblers) or it's supposed to be that way.

I guess the problem with the Stack Inserter is that they can't really adjust to insertion buffer limit of the assemblers as well as regular fast inserters can. The Fast inserters can respond to the "below buffer threshold" more often than the Stack Inserter because the stack inserter keeps on waiting for items to pick up from the belt... and in the time the stack inserter keeps waiting for more items the assembler runs dry.


That said... the stack inserters need more energy too... which becomes quite noticable if you have 500 stack inserters running instead of 500 fast inserters. The stack inserters surpass a few MW of energy usage quite fast... and some people are really picky on which inserter to pick for each job to minimize idle energy drain as well as energy required to move the same amount of items. And also they are more expensive to build in the first place.

If people wouldn't care about those things everyone would be using fast inserters for every application... but I often see that most people are still using normal inserters for jobs where the speed isn't of importance.

To pick up items from the train when blocked inserter got in hand 3 items (so everything will unlock).

There's this other thread where we're talking about being able to read a train's content via circuit network. I think these two ideas work great together.

Yeah that's one application the configurable stacksize bonus would be good for.

Another is Smart Furnaces... and maybe Smart Assemblers later on if they ever plan to enable recipe switching in assemblers via circuit signal... because then you could easily control which and how many items are inserted to prevent an assembler from being overstocked with resources. So basically it would make inserters more future prove if setting the inserter stacksize from the filter signals would be a thing.

[siggboy]

and in the time the stack inserter keeps waiting for more items the assembler runs dry.

If that happens then there's not enough throughput on your upstream, so it's not really a limitation of the stack inserter.

[Zeblote]

and in the time the stack inserter keeps waiting for more items the assembler runs dry.

If that happens then there's not enough throughput on your upstream, so it's not really a limitation of the stack inserter.

No, that's not the problem. Place down a level 3 assembler for something like copper cables - the stack inserter wakes up too late and by the time it grabbed 12 plates the assembler stopped.

[siggboy]

No, that's not the problem. Place down a level 3 assembler for something like copper cables - the stack inserter wakes up too late and by the time it grabbed 12 plates the assembler stopped.

OK, so there's an additional delay due to the stack inserter having to "wake up" first? That sounds like a completely unnecessary limitation to me (I haven't tried it yet in 0.13).

[Zeblote]

No, that's not the problem. Place down a level 3 assembler for something like copper cables - the stack inserter wakes up too late and by the time it grabbed 12 plates the assembler stopped.

OK, so there's an additional delay due to the stack inserter having to "wake up" first? That sounds like a completely unnecessary limitation to me (I haven't tried it yet in 0.13).

All work that way - they do nothing until the assembler has about 5 items left and then start moving. You can easily process 5 copper plates faster than it takes the inserter to grab 12 new ones from a full belt.

[siggboy]

Yes, but in that situation you needed more than 1 fast inserter for input in 0.12, so you're not worse off in 0.13 (you'd use 2 stack inserters, or maybe 1 stack + 1 fast).

[Zeblote]

Yes, but in that situation you needed more than 1 fast inserter for input in 0.12, so you're not worse off in 0.13 (you'd use 2 stack inserters, or maybe 1 stack + 1 fast).

If you use 2 stack inserters you will get the same problem as both start moving when 5 items are left and both take too long to grab new ones.

[siggboy]

Yeah, it seems as if Stack Inserters are probably not the best choice for feeding machines right now. I probably would have used Fast Inserters anyway even without knowing this, because they've become really good now that they can pick up 3 items at a time from belts (at full tech). That should be sufficient for most cases already, and you'll probably always have enough with 2 Fast Inserters (more than 12 items per second from a belt, the only item I can think of where you might hit that limit is when making gears, but you don't need those for making anything rocket related).

[MeduSalem]

Yeah, it seems as if Stack Inserters are probably not the best choice for feeding machines right now.

Except for the problem mentioned above by Zeblote where in extreme cases the Stack Inserter shoots itself in the foot it actually works fine. For example loading/unloading buffer chests from/to belts works as intended without noticing any delay because they are not bound to match an insertion limit (at least I didn't notice any delays for chests in a test I performed yesterday).

But for Assemblers it is somehow weird and I blame it on the Buffer limit of the Assembler the Inserter tries to match... and it gets worse once items get more sparse on the belt due to consumption further down the belt. The belt may still have enough items but once you force the inserter to chose/switch between near side and far side the insertion latency increases further and further due to bad item timings on the belt. I think the threshold of Buffer items insde the assembler should be a bit higher for Stack Inserters and it would fix the issue because then the inserter would cover "bad item timings" caused by the belt with the higher amount of items buffered in the assembler.

If that doesn't fix the issue than there is probably a bug somewhere.





Back to the topic... has anyone a better idea on how to set the stacksize via circuit network other than using the Filter Signals themselves with an option "Use Filter Signals as Stacksize" (Which still seems to be the best approach)?

Because if not then we probably have already a solution the majority seems to agree with, which means it is ready to be implemented as one of the priorities for the next circuit network update.

[MindChanger]

alternatively there could be option to set it only manually and by signal, as blue chests works now

[MeduSalem]

alternatively there could be option to set it only manualy and by signal, as blue chests works now

Maybe... like if you select a filter manually you can specify a number with it and that will be used as limit.

But if you enable to set the filters from circuit network and also opt in to use the filter values as limit for each type the manual setting gets overriden, whatever that may be.



I also thought about what if only FIlter (Stack) Inserters can set such a limit. Then the devs wouldn't have to fiddle around with the other regular inserters to find a way to limit the stack size there too in some crappy/odd fashion. So basically if you want to limit the stacksize for some reason you have to use a Filter (stack) inserter. Additional functionality coming with a price.

Because honestly we now have 7 inserters and the difference between Fast and Filter inserter and Stack and Stack Filter Inserter isn't all that big anymore anyways. If every functionality from the best inserter gets carried down to the low tech inserters than why the hell even have 7 different inserters in the first place... Then one Inserter would be already enough and make it upgradeable (including an option for speed boni or even have module slots for that) with all the options over tech research.

That's why I originally liked the Smart Inserters... the additional functionality (Filters, Circuit/Logistic network etc) it provided made it stand apart from regular Fast Inserters and it didn't feel that exaggerated on the amount of different variants/items. Currently it feels like some crazy mods out there that add a special inserter for pretty much everything.

[siggboy]

I'm also not so happy with the inserter situation right now (apart from the arbitrary color swap that has happened there are too many different inserter types).

The stack inserter is really good for loading/unloading wagons, but in end-game factories I don't really see a compelling use of it elsewhere. Maybe, if that buffer problem gets resolved, it will allow for some compact designs where you only have the space for 1 inserter (so you can't use 2xFast instead).

In all other areas, 2xFast is more than good enough, it's probably also cheaper (in terms of crafting and energy use, but I haven't done the numbers yet). The limiting factor in 0.12 was that Fast Inserters could not efficiently load from/to belts, but now that limitation is gone, and you get up to 3 items per movement from a belt. It's enough, you don't need to shove a compressed blue belt into a machine, like the Stack Inserter would allow you to do.

alternatively there could be option to set it only manually and by signal, as blue chests works now

This feature should be disabled by default and have to be enabled with an option ("Use signal value to limit stack size"). If it's enabled by default it's going to confuse a lot of people who are not prepared for it, or have never thought about the fact that a stack bonus can actually be too high.

Other than that it should probably look pretty much like blue chests work now. If you have enabled the feature, you can set a value in addition to the filter signal, with a slider -- up to the maximum stack bonus that is possible (12 or 2 depending on the inserter). If you feed a signal to set the filter, then the value would simply taken from the signal. If no legal value is specified, the inserter would use the maximum stack bonus (so you could set it to "-1" or 100k or anything like that if you want to unleash the inserter).

It will be more complex than before but I don't see how it would confuse beginners as long as the default behaviour is reasonable (Principle of Least Surprise).

[Cabanur]

I think the default behaviour for filter inserters should remain as it is. You can set up to 5 filters and each of them will try to use full stacks. The key here for not confusing new players is the GUI language. As it is now, the filters on the filter inserter screen have no numbers. Which makes sense, because it sets a filter, not a quantity.

If this idea comes to fruition, setting the filters through the circuit network should result in the filters have the amount filtered in the filter inserter screen. This is a very obvious difference that any player can instantly notice and promptly understand. If a player is too new to tingle with the cirquit network (or just doesn't care about it) he never needs to know the option even exists. He can use the filter inserters and it'll work as expected.

If a players likes to tinker and starts trying to use circuit networks to dynamically set filters, he'll inmediately notice the numbers on the filters. These numbers will behave in the same way as the rest of the cirquit network (several sources add up) which is a consistent behaviour and therefore fits the current mechanics while expanding on them.