Inserter-less compressed belt filtering using one combinator
Posted: Tue Jul 19, 2016 8:42 pm
by XKnight
As it is said in the title, this will be a contraption for filtering compressed express belt without inserters.
And no, we will not use this stuff, because it is no longer fun.
I will start from the demonstration how it works:
And something more complicated:
Video
As you might guessed, the core idea of this build is a perfect timing, and under word "perfect" I mean really perfect.
All properties of this contraption:
- only single line
- only express belt
- only full powered combinator
- requires protection if output belt is jammed
+ output belt is still compressed
+ can have multiple filtered items
+ filters can be changed via circuit network
Blueprint
Nope, just a regular printscreen.
After building this contraption it is very unlikely it will work.
At first you should build this:
Then you should throw manually 12 items on the curved belt (outer side).
And the last step is to build combinator-related stuff.
Only after this you can connect input and output belt.
That's all, no deep explanation just a perfect timing.
Have fun.
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Jul 19, 2016 9:08 pm
by siggboy
I love it. Shifting the bits to effectively count the ticks.
It's interesting that it works, I would have assumed that the timing will shift and the contraption would be unreliable.
(BTW there are no "shades of perfect", you should not be required to point that out . A better phrase would be "exact timing"required". And there are no shades of "exact", either...)
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Jul 19, 2016 9:12 pm
by XKnight
siggboy wrote:
It's interesting that it works, I would have assumed that the timing will shift and the contraption would be unreliable.
That's why this timing is a perfect for this build: one tick more and it will fail, one tick less and it will also fail.
siggboy wrote:
(BTW there are no "shades of perfect", you should not be required to point that out . A better phrase would be "exact timing"required". And there are no shades of "exact", either...)
As you wish, this timing is an exact timing for this build.
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Jul 19, 2016 10:21 pm
by siggboy
XKnight wrote:That's why this timing is a perfect for this build: one tick more and it will fail, one tick less and it will also fail.
How did you determine the values? Did you simply experiment or did you figure it out another way?
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Jul 19, 2016 11:17 pm
by XKnight
siggboy wrote:
How did you determine the values? Did you simply experiment or did you figure it out another way?
If you don't know where you should search for the answer, you will waste huge amount of time for all possible combinations.
So I started from the begining - belt and inserter mechanics: several different experiments with yellow/red/blue belts, with different belt orientation, with sideloading, undeground belts, with splitters, different inserters... until I was able to predict each smallest component.
Then I came to inserter-less filtering idea, and just found the most suitable components for it (that's why there is an undeground belt and a curved belt with outer line).
Indeed, "exact timing" exists for many builds (some of them might be unstable but this is another question).
But only this build requires single combinator, so it is just beautiful.
Re: Inserter-less compressed belt filtering using one combinator
Posted: Wed Jul 20, 2016 12:39 am
by siggboy
XKnight wrote:But only this build requires single combinator, so it is just beautiful.
Yes, it's a very good design, very, very deep into Dark Arts, but beautiful.
Your research explain the bug reports that you made in the past days. I was wondering "how does he run into that sort of stuff?" .
Re: Inserter-less compressed belt filtering using one combinator
Posted: Wed Jul 20, 2016 12:41 pm
by Qon
That's clever and compact. Protection from jammed belts should be possible with a pulse sensor and another magic number and combinator on the outputs, no? Allow one item to move for each pulse OR when next belt is hold = 0. Needs some refinement and testing.
Full powered combinator is guaranteed with a dedicated solar panel and accumulator so that one is trivially solved at least.
Re: Inserter-less compressed belt filtering using one combinator
Posted: Thu Jul 21, 2016 9:18 am
by sore68
Awesome!!!!!
If there is not a bottleneck, great!
Thank you for your solution!!
Re: Inserter-less compressed belt filtering using one combinator
Posted: Mon Jul 25, 2016 2:52 pm
by DOSorDIE
How can i use this to filter out 1 item type?
On the belt come many differnt items and i want only "iron plates" on the one side and the rest of the other.
I know how to set filters for inserter, but how i make this for belts?
Re: Inserter-less compressed belt filtering using one combinator
Posted: Mon Jul 25, 2016 6:51 pm
by XKnight
DOSorDIE wrote:How can i use this to filter out 1 item type?
On the belt come many differnt items and i want only "iron plates" on the one side and the rest of the other.
I know how to set filters for inserter, but how i make this for belts?
Instead of a thousand words:
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Jul 26, 2016 12:18 pm
by DOSorDIE
Great!
Thanks
Re: Inserter-less compressed belt filtering using one combinator
Posted: Mon Aug 01, 2016 11:40 pm
by dragontamer5788
Why x4 instead of x2?
If you're assuming only one item at a time, x2 should be sufficient, right? Did you originally intend for this to handle 2-items at a time and then scale back?
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Aug 02, 2016 12:58 am
by golfmiketango
So good it feels like cheating! There is no iron plate...
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Aug 02, 2016 7:47 pm
by RoddyVR
the fact that i cant even begin to understand why that thing works is a clear sign that i need to start playing a lot of factorio again.
best i can come up with is that the circuited belts after the spliter are only allowing space for an item to be added on the back when the next item that the spliter will put out is one that should go on their side.
but why the *4 and the odd 67mil number make that happen i cant figure out. are we feeding the output back into the input and multiplying it by 4 each tick, and is the 67 mil 4 to the power of number of ticks between items traveling on express belt -1 or something liket that? but then i dont get how it resets to start the feedback loop over again after letting the item go....
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Aug 02, 2016 9:40 pm
by dragontamer5788
RoddyVR wrote:but why the *4 and the odd 67mil number make that happen i cant figure out.
67-million or so is 0011 1111 1111 1111 1111 1111 in binary. In essence, the multiplication circuit is waiting 11-ticks from the initial pulse. (22-bits, two-bits shifted per clock as per the *4).
I don't know why he uses *4 instead of *2, which is why I asked earlier.
are we feeding the output back into the input and multiplying it by 4 each tick, and is the 67 mil 4 to the power of number of ticks between items traveling on express belt -1 or something liket that? but then i dont get how it resets to start the feedback loop over again after letting the item go....
Yes. 11-ticks for the item to get to the proper location on the belt. After five-ticks, the item is at bit-position 2^32 aka integer overflow. All numbers in combinators are 32-bit integers in factorio and are therefore subject to overflow.
Re: Inserter-less compressed belt filtering using one combinator
Posted: Tue Aug 02, 2016 9:56 pm
by siggboy
dragontamer5788 wrote:I don't know why he uses *4 instead of *2, which is why I asked earlier.
Every "1" that comes in as the LSB needs to get shifted out (past the MSB) after the correct number of ticks. You cannot pick the start position of the bit, it will always start as a "1" (when the item is counted). Then there's the appropriate number of ticks delay, in this case "13". After 13 ticks, if you shift by 2 bits at a time, your "1" ends up being 2^26 = 67108864. So that means that the splitter will release the item that has been "shifted into the counter" 13 ticks earlier. The bit also needs to be shifted out (past 2^31), which now only takes 4 more ticks, supposedly the time needed that it takes for the item to leave the contraption.
If you shift by 1 position (multiply by two), you could compare with 8192 (= 2^13), but then there would be almost 20 ticks remaining until the counted item is removed from the score. That would lead to other items getting past the splitter when they shouldn't.
You need to shift fast enough so that you can quickly shift out the bit after the corresponding item has passed the "checkpoint", so you will remove the bit from the counter entirely.
I have to give it to XKnight, it's genuinely clever -- understanding it is already difficult enough, but coming up with this kind of sh*t in the first place is really impressive.
(By the way I'm pretty sure he didn't explain it in detail on purpose, I think he enjoys reading how others try to wrap their heads around his crazy ideas in public )
Re: Inserter-less compressed belt filtering using one combinator