[0.13] Make inserter stack bonus individually configurable

[afk2minute]

Tbh, why do you need that (ok one use i know is "smart furnace design" but it was shown that it can be worked around)?
I really dont see any use of that....

[Cabanur]

Tbh, why do you need that (ok one use i know is "smart furnace design" but it was shown that it can be worked around)?
I really dont see any use of that....

To have a single inserter reliably move more than one item eg for loading trains: A chest with more than one item (for example a logistic network controlled blue chest) can't (right now) reliably provide to a filtered train wagon. The inserter will fill one of the items up and then stay stuck with something in it's hand while there is available space in the wagon and cargo in the chest.

[Deadly-Bagel]

Yes, I had filter inserters in mind. For normal inserters you'd have to specify a signal that is used as the stack size indicator (it could be set to "S" by default, like accus right now have a default output of "A"). The value of that signal would then set the stack size, without any filtering. No conditions or anything, simply use the "S" signal (can be unset if you want to explicitely ignore it, should rarely if ever be necessary).

Again, you're imposing your own logic on how you want it to work. Many systems work on a "demand" state where you will have a signal of -10 which means you need 10 items to fulfil that demand. This is often stored in a memory circuit. You then have an inserter (ANY kind, including filters) pulse what they move which counts off the value in the memory circuit until you reach 0 and the inserter stops.

I see the merit of what you are trying to suggest - a filter inserter that moves items based on signal alone would be fairly powerful, but this can be achieved in other ways fairly simply (usually by adding more inserters and connecting them to circuits individually). However this is a separate suggestion, it would not solve the problems we face here.

[Cabanur]

[...]You then have an inserter (ANY kind, including filters) pulse what they move which counts off the value in the memory circuit until you reach 0 and the inserter stops.

What if the count is 2, but your stack size is 12? Then the inserter will try to input 12 items, drop 2 and get stuck with 10, unable to move. This inserter is now blocked and useless until the target container makes room.

[Deadly-Bagel]

Exactly. So you need a configurable way of preventing this, thus why it should be a separate circuit condition.

[siggboy]

Exactly. So you need a configurable way of preventing this, thus why it should be a separate circuit condition.

The "circuit condition" would be the value of the "S" signal as per my earlier suggestion. You need to calculate the value of "S" in some way, and then you input it to the inserter, and from that moment it will move exactly "S" items per inserter action.

I don't understand how a "condition", as you call it, would change things in principle. Maybe you can provide a concrete example.

[afk2minute]

Tbh, why do you need that (ok one use i know is "smart furnace design" but it was shown that it can be worked around)?
I really dont see any use of that....

To have a single inserter reliably move more than one item eg for loading trains: A chest with more than one item (for example a logistic network controlled blue chest) can't (right now) reliably provide to a filtered train wagon. The inserter will fill one of the items up and then stay stuck with something in it's hand while there is available space in the wagon and cargo in the chest.

It will still be a problem with controlled stacks if you use multiple inserters probably. And using just 1 inserter to fill wagons is hmm not optimal to say the least.

[Deadly-Bagel]

I don't understand how a "condition", as you call it, would change things in principle. Maybe you can provide a concrete example.

Okay, so say you want to ensure there are 100 concrete in a chest using a stack inserter. Connect the chest to the inserter, tick "enable/disable" ([Concrete] < 100), and "limit stack size" ([Concrete] > 88). Assume the chest is empty, inserter moves eight times to insert 96 concrete, stack size condition is now met so inserter only moves one item four times to meet the 100 mark. No messy circuits, very simple to understand and implement. If there is a trickle output from the chest the inserter will simply keep moving one item unless it falls to 88 or lower, at which point a full stack of 12 is moved. It won't keep it at 100 as consistently as what you are suggesting but there shouldn't be any need if you're constantly taking from it.

For your method, you would attach an Arithmetic Combinator (100 - [Concrete] output [S]) - but as far as I can remember you can't set a constant in the first field! So you actually need ([Concrete] - 100) and connect it to a second Arithmetic Combinator ([S] * -1 output [S]). I think. Correct me if I'm wrong on that one. Alternatively, you can use a Decider ([Concrete] > 88 output [S] 1) to achieve exactly the same as above, but now you need a dedicated combinator.

As for using [S], name any circuit entity in Factorio that uses a specific, non-configurable signal for something, input or output (with the exception of item counts). If you do this, you make it a hidden feature that causes bizarre problems because you're using [S] for something else connected to an inserter and you didn't read the documentation. Therefore you would need to have it as a circuit condition anyway, "Stack Count" or something with the option to set the desired signal. There is no way around this.

Now, let's look at the advantages. Yes, having a Stack Size signal is somewhat more flexible, but I fail to see how the extra complication is worth it. As above, if you have a trickle output slightly faster than an inserter can move one item, both inserters will have the same activity so you're not saving any power, in fact you're using more because of the combinator(s). It doesn't "tidy" the circuit connection UI on the inserter (not that it would be messy anyway) because regardless of what you think, it does need to be configurable.

Can you provide some example where my solution doesn't cover something yours does?

[douglerful]

Registered simply too ask the devs to please please implement this variable stack inserter into the game. Maybe make it a separate item and not a global effect, an expensive late game inserter that can filter multiple items and change stack size per filter. Connect it to the circuit network and any signal present becomes a filter with its quantity set to stack size, this way you could have a single stack inserter that could grab any amount of anything controllable, and then a different amount of a different thing all via the circuit network. Make negative amounts in the signal result in the default stacksize of the filtered item. With this all you'd need is a single inserter set with Iron Ore-1,Copper Ore-2, Iron Plate-5, Stone Ore-2 and a smart furnace would actually be able to function without hackish solutions.

[gacekssj4]

I think that would solve my problem: viewtopic.php?f=41&t=16793

[MeduSalem]

Registered simply too ask the devs to please please implement this variable stack inserter into the game. Maybe make it a separate item and not a global effect, an expensive late game inserter that can filter multiple items and change stack size per filter. Connect it to the circuit network and any signal present becomes a filter with its quantity set to stack size, this way you could have a single stack inserter that could grab any amount of anything controllable, and then a different amount of a different thing all via the circuit network. Make negative amounts in the signal result in the default stacksize of the filtered item. With this all you'd need is a single inserter set with Iron Ore-1,Copper Ore-2, Iron Plate-5, Stone Ore-2 and a smart furnace would actually be able to function without hackish solutions.

Basically what we have been urging for several months already and there is not even a dev response to the thread yet, which honestly I just find sad at this point because a lot of people have been asking for that functionality already.

Though I think it shouldn't be a seperate item, it should work for all currently available filter (stack) inserters. It should just be an additional option inside the inserter menu that can be activated.

"Use quantity specified with Circuit Signal to set the Stack Size for that item type?" -> Check and that's it.

Just like this quick sketch I made (I took a Stack Filter Inserter, but it would apply to regular Filter Inserters too):

Stack Size Bonus1.png (396.13 KiB) Viewed 5181 times

It would take the circuit network filter signal to decide which items to grab and the quantity specified with the signal to set the stack size. That's all that's needed, that's all people have been asking for.

Rest can be done with Circuit Network... you want the inserter to move 10 Iron Ore per turn, just as example? Well set a constant combinator (or some other more elaborate contraption to determine your desired quantity) to output Iron Ore=10 as signal and hook it to the Inserter and activate both checkboxes from my picture above. Basically how siggboy already explained on the previous page:

Example:

"1 Iron" -> Only move "Iron", one item at a time
"10 Copper" -> Only move "Copper", 10 items at time; if your maximum stack size is "3", then move 3 items at a time
"1000000 Fish" -> Only move "Fish", use the maximum stack bonus
"-1 Rocket Silos" -> No filter is set

and so on.

It describes pretty well how it would work depending on various values.

Nothing else beyond that is really needed... an average player would be already more than satisfied with the option provided in my picture because it can handle Smart Furnaces and several other applications that have been presented over the course of the thread. It would even profit Trainloading, given you have a contraption to count how many items you already put into the trainwagon, but at least you could top it off instead of canceling the load procedure prematurely to prevent inserters getting stuck with items in their hands. That trains and individual trainwagons don't output their contents to the circuit network is a different usability problem altogether that somehow should get addressed, but it's not part of this topic... or only as a side note worth mentioning because its a case where both the inserter stack size problem and the trainwagon content problem happen crash into one another. Sorry to say for all the fanatic combinator contraption freaks, but any additional/further inserter options beyond my picture to handle special edge cases just shits for the birds because almost no one would use something that is too complex for its own good.

[ssilk]

Hm, I'm pretty sure the devs read this, but discuss, how to solve this and don't bother us, until they have a solution, that seem to be stable enough to tell us.

[MeduSalem]

Hm, I'm pretty sure the devs read this, but discuss, how to solve this and don't bother us, until they have a solution, that seem to be stable enough to tell us.

Well in something important like this I wish they would share their thoughts... sometimes it feels really awkward to be left in the dark about something.

[Deadly-Bagel]

Sharing thoughts as a developer can be dangerous so I don't blame them for that but at least let us know you recognise this as a problem =/ it's kind of worrying when we don't know if you want to fix this problem or not and that we might hit release without one.

Just a thought, there are flags to check an item will fit in the destination right? They stop trying to load when no more items of any type it can supply can fit. You could program inserters to move a maximum of items that will fill the remainder of the available space. True, this doesn't solve the problem when quantity is limited by the circuit network but it would be a good quality of life improvement for those who aren't using the circuit network. This AND a circuit solution would be ideal, so rather than one complex fix for everything you could do two simple ones.

[MeduSalem]

Sharing thoughts as a developer can be dangerous [...]

Well actually I think that sharing thoughts as a developer is better than not to... except if you are in a very competitive business where keeping secrets is the only way to stay in business, but I don't think it applies to Factorio since there's nothing comparable currently... They are on-top of a very lonely mountain. At least if you do some major changes/additions/removal without telling people ahead in time you risk having to clean up a huge mess afterwards with lots of people being disappointed, which is probably uglier to solve than to consider people's opinions beforehand.

At least I have seen on several occasions with other games or products when they did major changes without asking anyone... and they often didn't even have the damn courtesy to admit that they did something wrong, which made things even worse.



That said the Inserter Stack Size Bonus is nothing really game breaking now... the game works without too, but for some practical circuit network applications it would be a lot better if it was a thing.


Yeah I'm bad. I brought the thread back from the dead on purpose. But somehow I don't feel sorry about it because the unsolved issue really continues to irk me personally.

[Yoyobuae]

Yeah I'm bad. I brought the thread back from the dead on purpose. But somehow I don't feel sorry about it because the unsolved issue really continues to irk me personally.

Not just you.

[ssilk]

I remember many situations, where the devs made a change, that the community didn't like. First.

Best example is perhaps the change from 2^n stacks to what we have now. Before the stack sizes where 64 for iron or 128 for iron ore. Or was is 64 and 32? And now it's 50 and 100. Useless to discuss now, nobody would think, this was relevant (only minecraft players that think Factorio is just another minecraft clone ).

I just want to say, that I trust Wube enough
A) to see this is a hard game-limitation.
B) to care about this problem.
C) that they search actively for a solution.
Because they play Factorio themselves a lot.

[MeduSalem]

I remember many situations, where the devs made a change, that the community didn't like. First.

Best example is perhaps the change from 2^n stacks to what we have now. Before the stack sizes where 64 for iron or 128 for iron ore. Or was is 64 and 32? And now it's 50 and 100. Useless to discuss now, nobody would think, this was relevant (only minecraft players that think Factorio is just another minecraft clone ).

Call me odd but I'm one of the people who would prefer 2^n stack sizes over what we have now but I wouldn't make a fuss about it. Apart from the fact that I find 2^n progression more beautiful/harmonic there's also a developer perspective where I just think that 2^n stuff might have a reasonable performance benefit due to how one can use bit shift operations on them and spare the CPU some work on several occasions. But then again most Integer operations are single cycle anyways on nowadays CPUs.

I just want to say, that I trust Wube enough
A) to see this is a hard game-limitation.
B) to care about this problem.
C) that they search actively for a solution.
Because they play Factorio themselves a lot.

Yeah, I also think that this thread didn't went by unnoticed... at least not with how many pages it has.

And I think we as the community already have found a solution in the thread that would take care of the issue in a way that satisfies our needs: An option in (Stack) Filter Inserters for using the number/amount that comes with a filter signal as the Stack Size for that particular item type.

[Cabanur]

You probably remember since the stack inserter exists the requester chest's requests can be dynamically set via the circuit network. This means you are able to set it to request an arbitrary variation of 15 different items.

Now, think about how to use this. Say you have it request 5 different items. You can't put it in a belt, since inserters will only place in one side of the belt. And you can't reliably put this in any container without some serious circuit logic because of the inserter stack behaviour we're discussing about in this thread.

My conclusion is the requester chest circuit integration is useless unless you *only* configure 1 item at a time.

[ssilk]

Off-topic:

I just think that 2^n stuff might have a reasonable performance benefit due to how one can use bit shift operations on them and spare the CPU some work on several occasions. But then again most Integer operations are single cycle anyways on nowadays CPUs.

Are you serious? Tell me one thing in Factorio, where you need to divide by 2 once per tick, all the time? There is simply nothing, where this is really needed.
[Sometimes I use the "half stack" operation, but I don't care much about filling equal numbers into stacks (e.g.gun turrets, cause in the time I need to part that equally I can build a belt, that supplies the gun turrets with magazines and coal for the burner inserters...]

On topic:

And I think we as the community already have found a solution in the thread that would take care of the issue in a way that satisfies our needs: An option in (Stack) Filter Inserters for using the number/amount that comes with a filter signal as the Stack Size for that particular item type.

Yeah, but they change things sometimes slowly, and we cannot know, what other ideas they have; perhaps they have a deeper plan. And it also doesn't make much sense to discuss that, cause programming itself is a craftman's trade... we can only say what we want.