Request X number of items from a inserter

[Daandriks]

Hi everyone,

I've been playing Factorio for a while now. I would like to try things differently and be as efficient as possible. I am trying to work without the Logistic Network and also trying to build a factory where I could change the things build. So I've installed the Crafting Combinator. Therefor I can change the crafting recipe on demand. I searched the forum and it surprises me that there is not a perfect and easy solution for this.

• There is a chest in the end of the lane which requests 50 Iron plates (This number can change in the meantime)

• There is a chest in the beginning of the lane with Iron plates

• An inserter is placed in the beginning of the lane

• This inserter needs to grab exactly 50 iron plates. Not one more or less

I know I can make the inserter count the number of plates grabbed. I can also reset this counter. What I want is that the counter is reset after the 50 plates are placed on the belt. But also that the inserter is stopped. When a new request for x Iron plates comes in the process starts over.

• I cant seem to stop the inserter on 50 as the inserter is always stopped or the counter does not hit 50

• I can subtract the grabbed items from the requested ones but then it never hits 0, so I cant stop the inserter

• I can count the items on the belt, but then still it wont give me exact the x items and it still wont reset the inserter

It seems like a very simple task. Request x items to inserter and then just stop after x is reached. Just like how the Logistics Network is working but then for the Circuit Network.

Does someone has a solution. I would like to stay away from a looped belt.

[wobbycarly]

You could try setting the item stack override on the inserter to 5 or 10. Then when you count the number picked up, it won't overload.

[mmmPI]

+1 to the suggestion of setting stacksize to 5 or 10.

You can also try to set stack size using circuit, it is more advanced but it gives more flexibility if you want the same inserter to do different quantity and /or different material.

If you send 5 iron to the inserter that is set up to "set stack size" "set filter" "read hand content" "pulse" using red wire, you can use the green wire to connect that inserter to a the input of an arithmetic that does each * -1 , to do the subtraction, so the request could go 50-> 45 -> 40-> 35 with every pulse the inserter send and at 0 the red wire should be deactivated and not send 5 iron any more but nothing, so the inserter with no filter would stop. that's one way to "reset".

If you want to make sure the numbers for stack size and request can divide properly when the request is dynamic and not easy to set precisely as if generated by a crafting combinator, you can try to use the operation modulo % , if instead of 50 the request is 53, 53 % 5 = 3, so you can do a complicated logic to do stacksize = 5 at first, but then when there is still a request but quantity is <5, then stacksize = 3, one time, and the request would go 53=>48=>43=>...=>13=>8=>3=>0.

In other words i think to avoid the looping belt one has to make sure count is always perfect and it gets laborious quickly. Stack size to 1 make it easier to solve the problem, but also quite slow depending on what is the required throughput.

The robots themselves are not count perfect and often times bring more things than requested in requester chests, it is more visible with higher cargo capacity research.

It is not an "easy" task if you have dynamic request with numbers difficult to match with a stack size ( like 53 ), it may explain why you didn't found solution easily from research,also it may be easier if you load/pick-up from train or assembly machines rather than chests or belts.

[Daandriks]

+1 to the suggestion of setting stacksize to 5 or 10.

You can also try to set stack size using circuit, it is more advanced but it gives more flexibility if you want the same inserter to do different quantity and /or different material.

If you send 5 iron to the inserter that is set up to "set stack size" "set filter" "read hand content" "pulse" using red wire, you can use the green wire to connect that inserter to a the input of an arithmetic that does each * -1 , to do the subtraction, so the request could go 50-> 45 -> 40-> 35 with every pulse the inserter send and at 0 the red wire should be deactivated and not send 5 iron any more but nothing, so the inserter with no filter would stop. that's one way to "reset".

If you want to make sure the numbers for stack size and request can divide properly when the request is dynamic and not easy to set precisely as if generated by a crafting combinator, you can try to use the operation modulo % , if instead of 50 the request is 53, 53 % 5 = 3, so you can do a complicated logic to do stacksize = 5 at first, but then when there is still a request but quantity is <5, then stacksize = 3, one time, and the request would go 53=>48=>43=>...=>13=>8=>3=>0.

In other words i think to avoid the looping belt one has to make sure count is always perfect and it gets laborious quickly. Stack size to 1 make it easier to solve the problem, but also quite slow depending on what is the required throughput.

The robots themselves are not count perfect and often times bring more things than requested in requester chests, it is more visible with higher cargo capacity research.

It is not an "easy" task if you have dynamic request with numbers difficult to match with a stack size ( like 53 ), it may explain why you didn't found solution easily from research,also it may be easier if you load/pick-up from train or assembly machines rather than chests or belts.

Thnx for the input. But the logic for the % I don't understand to be honest. What is that doing?

I've found a solution on the internet but it is a task with heavy use of combinators. But it seems to work. And with some expantion it seem to work. But the downside is that if you interupt the proces it seem to break the fix aswell. And the downside is that I really don't understand how it works. It has wiring from the input of one combinator to the output of another. I don't get what that is supposed to do...

0eNrtWGuOmzAQvot/VrCKzTOo6kWqFSIw2VgFGxmzarriAD1IL9aT1IZNwhJDcNSqK7U/Esmvbx7feGbMC9qVLdSCMomSF0RzzhqUfH5BDX1iWann5LEGlCAqoUIOYlmlR1JkrKm5kO4OSok6B1FWwFeU4M65eTgTVB4qkDR3c17tKMskFyMM0j06CJikksKgTT84pqytdiCUkDNUATktQIxxHFTzRh3lTCug4Tahg44ocT0vfgiUmIIKyIcNakWZLAUv0x0csmeqANSpV9hUrRU9VKNn91Q0Mr0y7pkK2aqZs1LDDhey/KCt0j6VmXbwRg+qOhO9ogn6+f2HOsVbWbd34dZHpWHLZLoXvEopUzAokaKFbhDLBjN75bH+E1CM/UmL3pc5FXlLZT/sff8kANh0I5ludN4sR92jEkrWScGzUryrjV03knSKAGIZAfE7jYCPf53/cJYK/yoyTgQbt+N1zHk30sDS9Y1WkndB/j38NaBh0guNrjKW16BY7NVAH+6m0YIpf+1NxbPEGVCjGZ58e57i/zy93qgFf3trMyFZd5+Cs75UcObmB2ikkZyH4ERPqOgxIIVnpAoK2lYulMpaoWiveQkmzO0Fc6D8vkjGk1JClpexr12hlAX6dNjxVugeAfuPBpOis0n7rJEuZQ0ICeKGLeHK8D0peY7dhdB92wHlXC0uFoZP/fKrAAFZkR6yIbSlsrEZ0vxlRwPqJ7P8i5L8DU6rw8xJ9b4+rNNsPZXecldANmuzFDacNAZ8PNeEXpOK8QKpxIC9tcDeWGLjjQW4ZwuOLcCJLTixAA9swT0LcN8W3LfNaTi8M6eF0ywVGLJUaEpSOBjdviEfLBdaHE11vJ2r9rRUiW/V2+6SnFqdmXTcWjzu+ipUl5mEEQbZjB93Fo8Tf+rV+Lq3MSUJfClmjQQoZ+vi2JehDd9TTebqM15fg8axd12DTNixdZOGR31A1P1LbRle7suG+2py8ta+wwrMHRbZ3NWPBH+8H5le2vfWlYz1W894NNt7zD16CL6vAej5VsJ6rZPRNzUHPausO9SnGPvRlkRhGMRhHHfdL+bMlb8=

Copy blueprint

[mmmPI]

Thnx for the input. But the logic for the % I don't understand to be honest. What is that doing?

The modulo % could be seen as giving the remainder in a division there. So 53 % 5 or 53 % 10 would give 3 both, because if you divide 53 by 5 it will be 10 with a remainder of 3, and if you divide it by 10 it will be 5 with a remainder of 3, the operation % in the circuit network only output the remainder whereas the classic division gives the other number. I thought it would be necessary to use such operation to implement the logic precisely but the blueprint doesn't use this. At the very end is explained a risk of the blueprint's approach.

And the downside is that I really don't understand how it works. It has wiring from the input of one combinator to the output of another. I don't get what that is supposed to do...

The combinator looping on itself ac as a memory in the blueprint, it is easier to see if you slow down or pause the time which you can do from the editor, if you type /editor in command. It is considered a cheat and will disable achievement but to understood those i find it necessary . When a request is being fullfilled, this combinators input and ouput is the amount of material that has been grabbed by an inserter but is not yet in the end chest.

This is tricky, it requires to know and understand that every frame the value of the circuit network are updated, so a decider combinator like in the blueprint with each >= 0 output each, will take its output in a frame and use it as input in the next if it is positive or 0. This is how you can make it act as a memory. If you have such combinator setup , then when an inserter on the left grab an item with "read hand content" and "pulse" it will write on this memory, because during one frame there will be a value. Say the inserter on the left grab 5 iron on one frame, it will send a pulse with the value "5" on the channel "iron" during only 1 tick in proper wording. ( a pulse means sending a value during only1 tick ).

Then next tick, when the value are updated, this combinator will ouput the result it was given previous tick, so again "5 iron". And at this point the original input from the inserter on the left is gone, it's 0. But the next tick the combinator looping on itself will output its previous input if it meet the condition of > or = 0, so it will output "5 iron" , and again and again every tick as long as the condition is met.

If the inserter on the left grab a second time some iron, this time 3, it will happen that during 1 tick, the input will be the looping "5 iron" and "3iron" in addition, which will make the combinator loop "8 iron" from this point on.

The inserter on the left grabbing things is only 1 of the thing that write on the memory. it only adds up thing. But one also need a mechanism to write material off when they have reached the end chest.

This is more the task of the 2 combinators on the right part of the block of 4. This is another way to write on the memory, or in other word another way to provide value only during 1 tick similar as when an inserter grab something with the setting "read hand content" "pulse".

It takes advantage of the way the circuit network update every tick. If you make a long line of combinator where each one takes the output of the previous one and add 1. if you give a new signal at the beginning, the signal will propagate, it will take 1 tick to update the first combinator, and another for the second, and another for the third and another for the fourth and so one. So if you use 60 combinators the result is visible with 1 second of delay. 60 ticks.

Now in this case the red wire is split into 2 branch. One branch would be like a line of 0 combinator, and the other branch a line of 1 combinator. And then they meet again in the top right combinator of the block. It is not easy to see things this way because other things are happening but what this does is that it creates a delay of exactly 1 tick when the quantity on the red wire coming from the end part is changing. While other time canceling each other for the purpose of being the input of the top right decider combinator. That is a way to create a signal that last only 1 tick, which is a pulse, but this time a pulse with a negative value. Since the delay occur on the longer branch, which is longer because it does 1 operation on the signal, which is * -1.

So whenever the inserter on the left grab something the memory increase, whenever the quantity in the end chest changes, the memory decrease.
You cannot break/increase the memory by adding things on the end chest, because the top right combinator only allow negative value.

There is one thing left, which is how to set the stacksize with all this. The stack size is the difference between the quantity in the end chest and the request PLUS the quantity stored in the memory of material "on their way to the end chest". The PLUS and difference is done when the green and red wire value are added to act as input of the bottom left combinator. So if the request is 50 iron, the stack size is set to 50, which would in game translate to the max stack size. Whenever inserter on the left grab material they reduce their stacksize by the amount they grabbed. When the request is only 2 difference from the quantity in the end chest and the thing coming in on the belt, the stack size is 2. When the difference is 1, the stack size is one.

But it seems to work. And with some expantion it seem to work. But the downside is that if you interupt the proces it seem to break the fix aswell

One need to follow the wires to see this but it shows that there is a risk of overload if you use more than 1 inserter for the same ressource. Because if the stack size is set to 5 then 2 or more inserter can pick up 5 things at the same time while there would only be 5 things missing, not 10 or 15. Which will lead to too much material in the end chest. However, the memory will not be corrupted, the extra material that could be dispatched in such case would be accounted for if you request 500 iron later and there was an extra 10 from previous time , there will be a 490 request on the red wire, so it will not accumulate overtime which may spare the need for looping belt ?

Is this what you experienced when it broke ? It is an advanced blueprint ! I think it should work if used as intented but it's unclear how it was intented to be used

[Daandriks]

The modulo % could be seen as giving the remainder in a division there. So 53 % 5 or 53 % 10 would give 3 both, because if you divide 53 by 5 it will be 10 with a remainder of 3, and if you divide it by 10 it will be 5 with a remainder of 3, the operation % in the circuit network only output the remainder whereas the classic division gives the other number. I thought it would be necessary to use such operation to implement the logic precisely but the blueprint doesn't use this. At the very end is explained a risk of the blueprint's approach.

Thanx for clearing this up. No this blueprint is from someone else. I've tried it in Creative Mode. And it works, but if you create a line of multiple objects then it starts to overload.

The combinator looping on itself ac as a memory in the blueprint, it is easier to see if you slow down or pause the time which you can do from the editor, if you type /editor in command. It is considered a cheat and will disable achievement but to understood those i find it necessary . When a request is being fullfilled, this combinators input and ouput is the amount of material that has been grabbed by an inserter but is not yet in the end chest.

This is tricky, it requires to know and understand that every frame the value of the circuit network are updated, so a decider combinator like in the blueprint with each >= 0 output each, will take its output in a frame and use it as input in the next if it is positive or 0. This is how you can make it act as a memory. If you have such combinator setup , then when an inserter on the left grab an item with "read hand content" and "pulse" it will write on this memory, because during one frame there will be a value. Say the inserter on the left grab 5 iron on one frame, it will send a pulse with the value "5" on the channel "iron" during only 1 tick in proper wording. ( a pulse means sending a value during only1 tick ).

Then next tick, when the value are updated, this combinator will ouput the result it was given previous tick, so again "5 iron". And at this point the original input from the inserter on the left is gone, it's 0. But the next tick the combinator looping on itself will output its previous input if it meet the condition of > or = 0, so it will output "5 iron" , and again and again every tick as long as the condition is met.

If the inserter on the left grab a second time some iron, this time 3, it will happen that during 1 tick, the input will be the looping "5 iron" and "3iron" in addition, which will make the combinator loop "8 iron" from this point on.

The inserter on the left grabbing things is only 1 of the thing that write on the memory. it only adds up thing. But one also need a mechanism to write material off when they have reached the end chest.

This is more the task of the 2 combinators on the right part of the block of 4. This is another way to write on the memory, or in other word another way to provide value only during 1 tick similar as when an inserter grab something with the setting "read hand content" "pulse".

It takes advantage of the way the circuit network update every tick. If you make a long line of combinator where each one takes the output of the previous one and add 1. if you give a new signal at the beginning, the signal will propagate, it will take 1 tick to update the first combinator, and another for the second, and another for the third and another for the fourth and so one. So if you use 60 combinators the result is visible with 1 second of delay. 60 ticks.

Now in this case the red wire is split into 2 branch. One branch would be like a line of 0 combinator, and the other branch a line of 1 combinator. And then they meet again in the top right combinator of the block. It is not easy to see things this way because other things are happening but what this does is that it creates a delay of exactly 1 tick when the quantity on the red wire coming from the end part is changing. While other time canceling each other for the purpose of being the input of the top right decider combinator. That is a way to create a signal that last only 1 tick, which is a pulse, but this time a pulse with a negative value. Since the delay occur on the longer branch, which is longer because it does 1 operation on the signal, which is * -1.

So whenever the inserter on the left grab something the memory increase, whenever the quantity in the end chest changes, the memory decrease.
You cannot break/increase the memory by adding things on the end chest, because the top right combinator only allow negative value.

There is one thing left, which is how to set the stacksize with all this. The stack size is the difference between the quantity in the end chest and the request PLUS the quantity stored in the memory of material "on their way to the end chest". The PLUS and difference is done when the green and red wire value are added to act as input of the bottom left combinator. So if the request is 50 iron, the stack size is set to 50, which would in game translate to the max stack size. Whenever inserter on the left grab material they reduce their stacksize by the amount they grabbed. When the request is only 2 difference from the quantity in the end chest and the thing coming in on the belt, the stack size is 2. When the difference is 1, the stack size is one.

Nice explanation. But for me still it is a lot to wrap my head around. Always had some trouble with reading all the combinators and how they work. I was pretty accurate with math back in the day. But when it comes to count and those kind of stuff I do get lost sometimes.

One need to follow the wires to see this but it shows that there is a risk of overload if you use more than 1 inserter for the same ressource. Because if the stack size is set to 5 then 2 or more inserter can pick up 5 things at the same time while there would only be 5 things missing, not 10 or 15. Which will lead to too much material in the end chest. However, the memory will not be corrupted, the extra material that could be dispatched in such case would be accounted for if you request 500 iron later and there was an extra 10 from previous time , there will be a 490 request on the red wire, so it will not accumulate overtime which may spare the need for looping belt ?

Is this what you experienced when it broke ? It is an advanced blueprint ! I think it should work if used as intented but it's unclear how it was intented to be used

Yeah it seems like this is what I mean. Sometimes the output of the 4 combinators is a minus value. Also when I want to put this in practise it is not working smooth. Mainly because if you request say 100 iron for a certain chest then the plates cant be picked up in time by the inserter. So then I need a looping belt. Also I do get extra plates on the belt as I have to use multiple inserters for a more smooth operation. And they keep overflowing at a certain point.

But I've wrapped my brains a tad to much now to be honest. And I don't think there is a 'perfect' solution. Would have liked one but now I am going in to Combinator hell hole haha. So then it is better with the Buses of plates and stuff. But that gets boring at some point. So I was hoping to find a new way of doing it. Unless you have a option with perhaps a blueprint in it?

[Nosferatu]

Mainly because if you request say 100 iron for a certain chest then the plates cant be picked up in time by the inserter.

You could stopp the belt after the inserter IF there is iron on the belt AND the inserter is not finished picking up what he ordered.
But yes. What you are trying to accomplish is very hard.

[mmmPI]

But I've wrapped my brains a tad to much now to be honest. And I don't think there is a 'perfect' solution. Would have liked one but now I am going in to Combinator hell hole haha. So then it is better with the Buses of plates and stuff. But that gets boring at some point. So I was hoping to find a new way of doing it. Unless you have a option with perhaps a blueprint in it?

I would like to try things differently and be as efficient as possible

Well in the list "original" , "efficient", "not combinator-hell" it has become harder to get more than 2 with time

The looping belt i think is not as bad as it sound as a concept, you can make a flat loop wich look very similar to having 2 belts branching off a main bus to the side. Sure there may be some extra material there but it will not accumulate over time if you use the blueprint you linked with only a few inserter and having a set of request that is limited to avoid having many different material on the belt and saturate it. Say the starting brick would be switching only between iron gear and iron stick

I had made a blueprint some time ago that was somewhat similar which i was reminded of :

0eNrtmdFumzAUht/FlxOpwAGSIG1SpUXbRaVpXbubqkIEnMQaGGRMtajiAfYWe7Y9yWxIE8QgYOLQXuymUhLzY/+fzzk+7jNYhRlKKCYMOM8A+zFJgfPwDFK8IV4ovmO7BAEHYIYioAHiReKTGMc8wiZ+HK0w8VhMQa4BTAL0EzhG/qgBRBhmGJVyxYedS7JohSgfcFJIA0mc8mdjIt4v9EzTurI0sAOOac2vLP6mAFPkl0OgJlQYjUN3hbbeE+YS/Lk1DhmiLat5wpRl/JvDPMoRk1uxCj/OhB1GZT2ahMayUQNKaXxvnofcRK6bRWD+mAudGhMozWQ2DpOlAibfFDBZqmCyCj3/hxSXqTQXexwuXxVwuVfA5UYFl3spJqY0k/k4TO4UMGnfolDVVr90zFiyfCxDLZ96tUwSRCdJ6DFUWcdU16sls/iBkPK1qRAzxJ8NRYhUiygOhIN8MKZ+hlnxufChwQh7eKG19Utu1GpC1gdu1LtGjZYtMRte3i7rxLUCJz7JODEfXlAu68QXBU7cyjixGJ7GL+vEUoET9azZ6YahHyQwjcnE36KUnU6WexcGpy2jJW0ZxwbBo5htI8Sw35XCTUkyR2WX/xzgw/zXmKbM7W008vyt8DlFQsZ92UrAmfBVxDzxe+U0wDv+aJyxJJMWz6VM1otaAlsHWBXHiwdgTyrHFiFAPg54SetAYksi2csq5SFbTqLEo8WCHPBhMDAhlOzcIvTcNY0jFxMuAxxGM9RGk6KgjgpC0Ur3PgLsqTcIGeY/jNt0pz13w3RAjM7/x2hjyMGOkG3A1wzFlAxRW3+NEPXIjm0x2ZSB8sJCr4Xfn1+/h9B4QrSqriIMG3D1jJ6OqLR6YrVkscLXwHp7muf7t0LTrDPSTlKRZVhTs9ugHpuzCAU4iyYo5LOnPIsmcYgasZo9Tl495tjWLhqzM/pFONbFxtAT8Wep0/D8jIYRvvXWWc6KxRkdIxzrul5XcF3faQXUpa1YjGPFx9doGaFxRgcN3/pdwo2UFXD4neN4qdPoceHY4/xTnlP4Gai453Qq/0TUAC/YabmGuWHOFnBmTxe2ZZp5/heuX4it

Copy blueprint

Here you a request value, set to 300 copper plate, on the constant combinator, the request is sent on the right power pole if it is larger than the value T in the bottom combinator. The value T can be increased so that the request doesn't trigger for any arbitrary number you want. It is a different way of doing the "request x number of items" it doesn't look at the inserters, only at chests. It uses the same notion to generate pulse and store them in a memory similar to the one you posted.

There would be countless variations to match a particular desired behavior, the signal on the right power pole can be used to set the stack size or filter to some inserter, and the threshold value can be a function of the number of inserter to anticipate overloading and not trigger the actual request if some could happen. something along the line of : if 5 inserter, and max stack size is 12, the request should only trigger if 60 or more. This way you never have excess material, instead always a little less : when request is 53 it would be ignored, and a request of 63, would only see 60 provided, and then the request being 3 would be ignored.

Again it is the territory of heavy combinator usage , i don't have a "perfect solution" that match the 3 point of the introduction list

If you could develop your plans to use the crafting combinators, maybe it would help pointing towards certain easier solution to implement.

for example, you want to use all assembly machine for any material ? or do you have some specific set of receipe permuation in mind ?
do you plan to use it for every single item in game ? or more in a mall kind of thing ? or for things like green circuits ?

depending on the use case, you can rule out some scenarios, and make it easier to have dedicated solution, if you have excess material for green circuits it's fine, it would only be copper and iron, maybe it is possible to have some buffer chest that would keep the material for later use instead of having it looping back, if you need a looping belt for the mall thing, maybe it can be put in the center of the mall and be reused by all machines to make it more compact and efficient, i am not too familiar with the crafting combinator mod, but i think i remember it can void item if you change the receipe when there is production not finished or when there is material loaded already for the next production, maybe it can be used to simplify some things at the cost of some material.

You also are making it more difficult by not using robots, those purple chest would do marvel here

[Daandriks]

Hi all,

Thnx for the replys! I stopped my idea and just going back to the regular game. Had some time off and no time to play. So therefor I had no time being here. But wanted to thank you all!