Loop
If item# = 1 and chest1.contents > 0 then
Move one item from chest1 to belt
item# += 1
End If
If item# = 2 and chest2.contents > 0 then
Move one item from chest2 to belt
item# += 1
End If
If item# = 3 and chest3.contents > 0 then
Move one item from chest3 to belt
item# += 1
End If
...
...
...
If item# = (last item) and (last chest).contents > 0 then
Move one item from (last chest) to belt
item# = 1
End If
End Loop
Basically I just want it to cycle through a collection of chests, inserting one item from each but waiting if the chest is empty. The end result should be a set order of the items on the belt.
Re: Combinator Confusion
Posted: Tue May 04, 2021 4:55 pm
by DaveMcW
Loops are very difficult to make in combinators. You should rewrite your program without loops if at all possible.
There is an elegant one-combinator solution if every chest contains a unique item. Wire every chest to a decider combinator with the condition "Each > 0 → C = 1". This counts how many chests are non-empty. Then you can set all your inserters to operate when C = 4, or however many chests you have.
If you require some chests to have duplicate items, you need one combinator per chest to detect empty vs non-empty. It would be "Anything > 0 → C = 1". Again, have your inserters operate when C is equal to the total number of chests.
You can also use C to count extra conditions. Calculate the amount of free space on the output belt, and ouput C=1 if it can hold everything. This prevents blocked output from breaking the system. You can also have a timer output C=1 to limit the number of inserter swings.
Re: Combinator Confusion
Posted: Tue May 04, 2021 4:59 pm
by Durr
That sounds like it should work perfectly. The order doesn't matter really as long as there is one of each item pulled before a second item is pulled from a chest. Each chest does have a distinct item.
Thank you!
Re: Combinator Confusion
Posted: Wed May 05, 2021 6:16 am
by Bauer
A 1:1 implementation of the original code would be:
A counter [const A=1 into a looped "A<N" output input-count]
This signal goes into a selector per chest "if A=3" then output B=1.
Multiply B with the content of the chest.
Use this to activiate the inserter is the product is ">0".
If all chests have different content, need only one selector (+ an alphabet in a constent combinator or chest) and one multiplyer.
A 1:1 implementation of the original code would be:
A counter [const A=1 into a looped "A<N" output input-count]
That is a for loop, the original code is a while loop. The counter should only increment if an item is found in the chest.
Which reinforces my point that loops are very difficult to make in combinators.
true and true.
Re: Combinator Confusion
Posted: Wed May 05, 2021 5:15 pm
by Durr
Here is what I came up with with your help:
Each chest has a decider and a constant combinator. The decider outputs C = 1 if there is anything in the chest. The constant outputs T = 1.
At the end of the line each item gets separated and has a buffer chest with a decider, if the buffer chest has less than 5 items in it the decider outputs a 1 on it's unique signal (the first buffer chest is signal 0, second is signal 1, etc.).
Somewhere in the network I have a decider that outputs Z = 1 if C = T.
For the inserters at the source chests, I have an arithmetic combinator that adds Z and signal 0 (or signal 1, 2, 3, etc., for the corresponding buffer chest) and outputs the result on Y. The inserter operates if Y = 2.
This should keep a 1:1 ratio of items being put onto the belt, and accommodate a backed up item at the end of the belt.
Loop
If item# = 1 and chest1.contents > 0 then
Move one item from chest1 to belt
item# += 1
End If
If item# = 2 and chest2.contents > 0 then
Move one item from chest2 to belt
item# += 1
End If
If item# = 3 and chest3.contents > 0 then
Move one item from chest3 to belt
item# += 1
End If
...
...
...
If item# = (last item) and (last chest).contents > 0 then
Move one item from (last chest) to belt
item# = 1
End If
End Loop
Basically I just want it to cycle through a collection of chests, inserting one item from each but waiting if the chest is empty. The end result should be a set order of the items on the belt.
How about something like this? Each belt has a decider combinator that acts as an SR latch, holding the value from the pulse as an item passes over the belt. This in turn locks the previous belt segment so that the next item cannot advance. There is also an arithmetic combinator which multiplies the pulse by -1, and outputs it as the item that is locking the next item in the loop. This makes sure that it does not signal the next in the loop to go until it has an item to provide.
Loop
If item# = 1 and chest1.contents > 0 then
Move one item from chest1 to belt
item# += 1
End If
If item# = 2 and chest2.contents > 0 then
Move one item from chest2 to belt
item# += 1
End If
If item# = 3 and chest3.contents > 0 then
Move one item from chest3 to belt
item# += 1
End If
...
...
...
If item# = (last item) and (last chest).contents > 0 then
Move one item from (last chest) to belt
item# = 1
End If
End Loop
Basically I just want it to cycle through a collection of chests, inserting one item from each but waiting if the chest is empty. The end result should be a set order of the items on the belt.
How about something like this? Each belt has a decider combinator that acts as an SR latch, holding the value from the pulse as an item passes over the belt. This in turn locks the previous belt segment so that the next item cannot advance. There is also an arithmetic combinator which multiplies the pulse by -1, and outputs it as the item that is locking the next item in the loop. This makes sure that it does not signal the next in the loop to go until it has an item to provide.
Although I think given your latest post, that's not really the end goal, and a better option may be to use a counter to keep track of the number of items on the belt, using a belt segment in pulse mode on each end feeding into a decider combinator in memory mode (item != 0 output item). If the far end sensor is sent through a arithmetic combnator to multiply by -1, it decriments the memory counter when the items reach the far end. Along with the corresponding signal for the chest contents. You can enable the belt to allow items onto the belt only if the number of items in flight is less than some number, and that the number in flight and already at the destination is below some upper limit. This leaves the shared belt contention free, with potential for setting a total limit lower than can be easially stored in the buffer at the far end, and small transfer sizes, allowing efficient use for multiple items.
This example has the total limit to be released to the chest at the far end on the constant combinator with a setting of -25. The one on the left limits the number of items that can be on the belt between the sensors at one time. Note I didn't build in a way to reset the counter if you pick items up off the belt other than to disconnect the green wire between the decider combinator's input and output. It's also not possible to read pulse to one color of wire and hold to the other color of wire, so this can possibly send as many as 4 more items for single lane, or 8 items for double lane than the buffer is set to.
Re: Combinator Confusion
Posted: Thu May 06, 2021 4:28 am
by quyxkh
Here's a two-combinator version (plus a constant) that works for any number of chests and item types. In the picture the fourth chest from the right is empty, so everything's waiting. So long as you have less than I think 13 chests you can unload at full speed. Number the inserters, set the nth inserter to enable-if C=n, read pulse, stack size 1.