Max-moduled stone brick smeltery

[quyxkh]

Hey, I've been spending pretty much all my puzzle-solving time on the compression-detection circuit, and came up with something I regard with approximately equal amounts of horror and pride:

Time-to-compression meter, rightmost pole reads current and last-uncompressed time

snap@T20011360=1270x429+152.0625-19.90625,z2.jpg (55.63 KiB) Viewed 3397 times

blueprint

0eNrtW0tv4zYQ/iuFjq28EEk9jbaXnnpoDlkXCFAEhmwxCQFbMig62CDwfy9lrR3HenCGfmY3l83KkoaPb74Z8hvq1ZnMlnwhRa6c4asjpkVeOsP/Xp1SPObprPpNvSy4M3SE4nPHdfJ0Xl1lfCoyLgfTYj4ReaoK6axcR+QZ/+YMyco1GkilUE9zrsS03QZd3bsOz5VQgtc9Wl+8jPPlfMKlbsRgynUWRanfLvKqD9riIPoSuM6L/g/VzWRC8ml9l7qOHraSxWw84U/ps9Bv61fezI717WxtqqxuPAhZqnFjfM9CqqX+Zduv+okBT6dP1cCqqVVpNc8D3fdiwWVat+/8qt8plmqxRFtd1Xbzeijr3pHqn0fJeb47ayKrxynkdCnU+nKN0u7tvfsaAW2dVuYkz4zG7qvONFCifR7ThCjAQfTd5mH4pPmLehL543uMvOpivkjluqdD508LjO5qk4sX3cFlrsYPspiPRa5tOMOHdFbyLvha5ps0wHHbUSZNYLpRJFHj6Q6zrN95CIH5A8P5A7uAP9z1O8IfFo7wd48jKLlE+QGBItag83vE/F7HSJqxoA1OfzvSzYT14klbwQzbwXwQM8VlRzYygLfchNltRrpHTLE9KdpnKdj2kn9bSF6WAyXTvFwUUg0mfKZaHD9Zz5S3ap+aTaM8TyczPs5EWf39HlTe+iR5mo2f0jyrCKF0p8ra3d6e2PxePzovMr5tFDJTIWz8IY70mzztnY/zo+Nznj9zuZtYjkH+YD9l97Aflc0TGJARes0VbgI4+eHXXG2LJArN2gkGrdgy+ca4aD2IMdBZhevRbrimduE6gqWqBO27ASoOnc51vfee+5vdAgThtkn/yiE8KLK4fRl0vylCoak4glGAeNupmfNMLOcDPtMzIrUvLAqdQlu8YEOCNmvEcjlLPvRydnS8jBb148+sF7u9e1cGCxmEomMGu5KYwQ7PdreHxYwtAO14+UAIkBtGcgGG3VZTX/LKBvylrzVeO0z83QKjmyMqDDSEko34KI0hANsNgEHcR/OSXISXt72JfGAB+Fek5kcMuk0L6P28DYG8DVC8JTVpvS/Be3z8E9L2phExT0pHrM5jWhkFYEHQZCk5DZtpDGQzTh6g51cH7j6GOoDQrQJctmZAoYtEVlB+8OXwKbA0iLck7A/rfjf0PhJ6YKGHxMiNlf8GvfUCZW+zAM1NCcpLo8vnJnpluSkB554AlVsSHMCdRUfPVnAnlxDcCaqICy28Eiuxj55J67MszUAdgNpVHMiPUHUe2e4J2/3N66VsZNhegAUcQ2wHKtyUWau85y1QjI4u8Y4OrEy4RokMLqiZTgc0WvOB8PrWgtxF4a1KG+eV46hh00eD4+oCxORP0MgdWCNMr4jAg9MT2EcKN8ACCQ3tBNdPvRV9ois2RkHXoOV1Si++YfuIdB5isEcNZRyoFEQja2H3o7P/X+xhTqSEAxVuaYwTbs9P/5uPoeAwb3/36kN3zU2sTNrvHt0SHL2hGg9NrHyDfvrG/oQ3lA2wmt8WSo8h3TIPpxd4CNpbyQU3u3IBs5MLoHmHEZvB0zMN3lIrocBDfQx9yuEye6qTHIyy+YwiNpxZMWn30aEKfH9e6cSZ2eJMf06cDcfgGMPVaPBFtv4c0YkzWiQJroTPF/ouykRYFmKKGC05p6s4AtySs8AW0J/0QzcTM1mEAjQBAwoUuRhOY4k+91jgQqQRaGBZ3FCojA0Nde2uWWSF/OV2UORad1Ch7VmXfmTbzxBo2+uvl4c7X0u7ziydcD1+5y89QVWRWff5l3+4Xuzre3rIZf1xm+/TiDAvjr3V6n8q5xV8

The two belt segments on the left are settings templates and wiring pads for the input and output belts on the rig under test: delivery is upwards so the bottom one is sensibly the input-belt template and wiring pad, the top one the output template and wiring pad. Copy and green-wire the input template to one segment of each input belt, copy and red-wire the output template to one segment of each output belt, for one blue belt of output everything's automatic from there. If your output's through something other than a single blue belt, the center pair of multipliers are the expected-rate calculators, wire the number of ticks it takes one lane to deliver one item (three ticks for blue belts, six for red, nine for yellow) into the upper multiplier's constant, and the negative of the number of output lanes you're metering (-2 for one belt, etcetera) into the lower of the pair.

The counters all reset automatically and the clock starts ticking as soon as the input starts. Everything stops when the input stops. The pole at the right carries `T`, the current runtime in ticks, and `U`, the last tick where output wasn't keeping up with the expected rate, and some internal bookkeeping. Should be pretty easy to wire that to your lamp display or some nixie tubes. This works off a single segment of each belt, and the compression detection works off pulse reads, so there's no delay on compression detection.

(edit: whoops, the ratio I gave above for redbelt throughput's wrong, 9 slots at 2 slots/ tick means you one item per lane per 4.5 ticks, so make the numerator 9 not six and the denominator -2 * lane count for red belts, since you can't dial in 4.5 for a numerator. 3 and -1-per-lane for blue belts and 9 and -1-per-lane for yellow belts are correct)

[golfmiketango]

Equal amounts of horror and pride

Man, I know that feeling.... Hmmmmm, werry eeenteresting!

This gets me thinking....

gmt's compression detection conjecture:

There exist positive nonzero integer constants c and k for which it is possible to build a compression detector combinator circuit that inspects any single vanilla straight belt entity (that is, only one red wire goes to only one belt tile) wired in either "read-pulse" or "read-hold" mode, capable of rejecting or accepting the null hypothesis of a fully compressed belt without any errors, within 3c+k ticks for yellow and red belt and c+k ticks for blue belt. (extra conjectural credit: state the minimum possible c and k). [Edit: some simplifying assumptions: Items may not be added to or removed from the belt within the tested belt segment by any modded or non-belt, non-splitter, non-underground entity; the contraption is allowed to return a result about the situation some ticks ago, and only required to reject the null within some window of ticks (probably 3 and 9 respectively), not at any precise moment. Also, I wonder if 3c+3k ticks would be a more powerful specification for red and yellow belt].

Maybe it's time I internalize the stuff in the wiki about belt motion and item holding mechanics (looks like you already did, quyxkh). Much of the work I did on my compression detector was done in an "atheoretical" manner--that is, by dinking around and seeing what happens without attempting to understand why, which probably won't cut it for thinking this through.

[golfmiketango]

Equal amounts of horror and pride

Man, I know that feeling.... Hmmmmm, werry eeenteresting!

This gets me thinking....

gmt's compression detection conjecture:

There exist positive nonzero integer constants c and k for which it is possible to build a compression detector combinator circuit that inspects any single vanilla straight belt entity (that is, only one red wire goes to only one belt tile) wired in either "read-pulse" or "read-hold" mode, capable of rejecting or accepting the null hypothesis of a fully compressed belt without any errors, within 3c+k ticks for yellow and red belt and c+k ticks for blue belt. (extra conjectural credit: state the minimum possible c and k). [Edit: some simplifying assumptions: Items may not be added to or removed from the belt within the tested belt segment by any modded or non-belt, non-splitter, non-underground entity; the contraption is allowed to return a result about the situation some ticks ago, and only required to reject the null within some window of ticks (probably 3 and 9 respectively), not at any precise moment. Also, I wonder if 3c+3k ticks would be a more powerful specification for red and yellow belt].

Maybe it's time I internalize the stuff in the wiki about belt motion and item holding mechanics (looks like you already did, quyxkh). Much of the work I did on my compression detector was done in an "atheoretical" manner--that is, by dinking around and seeing what happens without attempting to understand why, which probably won't cut it for thinking this through.

I was unable to play factorio today, due to not being able to boot linux, because, in turn, reasons.

So I finally got around to reading the wiki. Interesting stuff. So I think the broad sense of my conjecture is true. But I am less optimistic than I was about the smallness of c.

If the wiki is accurate (I assume it is) but also "covering" in the sense that it describes all the limitations placed on belted logistics in the game engine, then here is what is going to make this measurement inherently nontrivial:

Code: Select all

 
Step by step movement of an item on a belt-lane. <---*---> represents an item, and the slots it consumes.
  
   |==============================|  <-----  32 slots
1  <---*---><---*---><---*---><---* 4 items
2  ><---*---><---*---><---*---><--- 3 items
3  -><---*---><---*---><---*---><-- 3 items
4  --><---*---><---*---><---*---><- 3 items
5  ---><---*---><---*---><---*--->< 3 items
6  *---><---*---><---*---><---*---> 4 items
7  -*---><---*---><---*---><---*--- 4 items
8  --*---><---*---><---*---><---*-- 4 items
9  ---*---><---*---><---*---><---*- 4 items

Great. So for a single-lane of yellow belt, we just have to check that "hold"<4 is never true for four ticks in a row. This technique is more complicated for red and blue belt, let's not even think about that yet, because we have a bigger problem: there are two lanes. This means the above diagram now explodes in complexity because there are nine different possible ways to fully compress a belt:

Code: Select all

(1) <---*---><---*---><---*--->
    <---*---><---*---><---*--->

(2) <---*---><---*---><---*--->
    ---*---><---*---><---*---><

(3) <---*---><---*---><---*--->
    --*---><---*---><---*---><-

and so on. So those "4"'s and "3's" we had in the single lane are now going to make some combination of interference patterns... I haven't entirely thought this through. Obviously the interference patterns will not be interesting but just various ways of arranging the numbers 6, 7 and 8 into a nine-dimensional vector with sum 64.

Furthermore, I am pretty sure that "pulse" mode helps not at all. I can't prove it, yet, but I now have a strong intuition that using pulse or hold as the input will have at most O(1) impact on any fully optimized single-tile compression detector circuit -- I think they are basically equivalent*

There is a big assumption here: that all of the above configuration of items on a belt are actually achievable. This may not in fact be so, and I think the first step in figuring this puzzle out is to prove either that they are, or they are not, possible, using the 9-tile inserter timing tricks everyone keeps mentioning. So I guess the really, really first thing is to reproduce those inserter timing builds, figure out the nine different patterns we'd expect to see on a yellow belt, and see if they are all actually achievable or if some sort of lane-item-alignment god forbids various configurations.

* At least, in vanilla factorio where all belts move an integral number of "belt-item-slots per tick".

[golfmiketango]

There is one other note. It's tempting, because it just "seems less confusing" to try and do all of this work only for straight belts.

But maybe there is some sense in which a curved belt is in fact better for determining compression. In fact I kind-of suspect this is the case, but somehow I just irrationally don't feel as excited about figuring compression detection using curved belts first.

[golfmiketango]

figure out the nine different patterns we'd expect to see on a yellow belt

Actually in pulse mode we won't even need to do this -- just look for the correct pulse-gap-patterns we'd expect to see on an oscilloscope which is absolutely trivial to do (assuming we have the inserter timing thing up and running).

[quyxkh]

If you change your viewpoint a bit, that's what that circuit counts. The actual counting is a small fraction of it, 6/33 combinators (the lower-left six) to count up +ve-full-lane-slots-delivered and -ve-lane-slots-delivered, 16 to keep track of the last low-water mark on the difference—making it able to conditionally record results and record every tick if needed, while delivering the latest recorded result within three ticks, was a challenge—and 10 for the self-reset circuitry.

Each tick, each yellow, red or blue belt lane delivers one, two or three item slots. Each item pulse is nine full slots. If the belt's compressed, you'll get 9 full slots per 9 item slots, I wanted to count items not item slots so I reduced the fractions, don't think that was worth it. To avoid polluting the wire I use signal=0 as the "true" condition and wire a -ve of the value I'm looking for to the input, for instance look at the bottom left decider pair: the bottom one is reading Anything > 0 from the input segments's hold count and outputting T=1; that's the clock-increment signal, while there's items on the input belt segment, the clock increments; the decider above it is T=0⇒Everything=input count reading the clock-active output, a T=-1 constant, and the output-belt-segment pulses. The bottom left `+` is a straight clock accumulator, T+0⇒T reading its own output, the clock-active signal and a reset signal. T and U are the current and last-uncompressed clock, R and S are the current and last-low-water-mark -ve missed-item count. X is the reset signal, N is the memory-cell address, I use `-` combinators for delay/rename/isolator. The T=-2 constant above the inputs is compensating for reset-detection delay, the two constants on the right are memory addresses and the rows to their right are the two memory cells, the low address bit is the write-enable, the two `<` deciders at the top right are address alternators so the two memory cells function as one, the rest should follow pretty easily.

[golfmiketango]

If you change your viewpoint a bit, that's what that circuit counts. The actual counting is a small fraction of it, 6/33 combinators (the lower-left six) to count up +ve-full-lane-slots-delivered and -ve-lane-slots-delivered, 16 to keep track of the last low-water mark on the difference—making it able to conditionally record results and record every tick if needed, while delivering the latest recorded result within three ticks, was a challenge—and 10 for the self-reset circuitry.

Each tick, each yellow, red or blue belt lane delivers one, two or three item slots. Each item pulse is nine full slots. If the belt's compressed, you'll get 9 full slots per 9 item slots, I wanted to count items not item slots so I reduced the fractions, don't think that was worth it. To avoid polluting the wire I use signal=0 as the "true" condition and wire a -ve of the value I'm looking for to the input, for instance look at the bottom left decider pair: the bottom one is reading Anything > 0 from the input segments's hold count and outputting T=1; that's the clock-increment signal, while there's items on the input belt segment, the clock increments; the decider above it is T=0⇒Everything=input count reading the clock-active output, a T=-1 constant, and the output-belt-segment pulses. The bottom left `+` is a straight clock accumulator, T+0⇒T reading its own output, the clock-active signal and a reset signal. T and U are the current and last-uncompressed clock, R and S are the current and last-low-water-mark -ve missed-item count. X is the reset signal, N is the memory-cell address, I use `-` combinators for delay/rename/isolator. The T=-2 constant above the inputs is compensating for reset-detection delay, the two constants on the right are memory addresses and the rows to their right are the two memory cells, the low address bit is the write-enable, the two `<` deciders at the top right are address alternators so the two memory cells function as one, the rest should follow pretty easily.

This is kind of greek to me as I "haven't had the chance" to play with this stuff since 0.16 dropped (busy making outposts mostly ).

So does the above say, in essence, that you're only looking at the one tile for purposes of compression detection, and the second belt tile is only being read in order achieve some secondary feature, i.e., to activate or deactivate the whole apparatus or control the input? What is the ultimate invariant you're using to accept or reject the "compression" hypothesis? I do intend to take a serious look at this but I needed to get some kind of rudimentary numerate understanding of how belts actually work (not hard since it's all spelled out quite clearly in the wiki).

It seems to me that the hardest part of this is avoiding false positives due to the various possible patterns of items on the belt. But I think I see what you're getting at above. If we just remember when we saw the last two item pulses on the belt, then we can theoretically expect another pulse in 9/(belt-speed-multiplier) ticks after each of those, respectively, right? But what happens when you have red belt and that is not a whole number? I don't yet know the details and don't dare mess with factorio just yet (I almost have my computer back... although I love pretty much everything else about it, the main downside of running a Gentoo desktop is, if you pull carelessly on fraying threads, it occasionally can unravel, forcing you to just stop using your GUI and make do with a text-only environment while you un-break your box by recompiling your entire system).

[quyxkh]

If the belt's compressed, you should get nine full item slots for every nine item slots. The bottom belt segment is the input/activation detector template, the top segment is the delivered-item pulse meter template, they're there to make settings copy/paste convenient.

So it counts (with reduced-fraction numbers) expected item slots as -ve of tick count * lanes * belt speed and delivered item slots as 9*pulse count. The input belt segment is wired only to {,de}activate and reset the clock and meter, the output belt segment to read delivery pulses. You could wire the input detector to one segment before the output detector if you wanted.

[golfmiketango]

Sweet. So my conjecture was correct and c is optimally three (because, from a dry start, with red belt, we don't know if we landed on the fudged half tick, or a compression loss, if we see a five tick lag between the first two putatively fully compressed items, and have to wait for the third item to arrive in four ticks before we can be sure about it), and k is probably a matter of how good we are at combinators and optimally zero (one? anyhow, probably it can be small). Yay I feel smart because I'm lucky!

[golfmiketango]

{,de}activate

Nice use of brace expansion by the way

[golfmiketango]

Hey, I've been spending pretty much all my puzzle-solving time on the compression-detection circuit, and came up with something I regard with approximately equal amounts of horror and pride:

blueprint

0eNrtW0tv4zYQ/iuFjq28EEk9jbaXnnpoDlkXCFAEhmwxCQFbMig62CDwfy9lrR3HenCGfmY3l83KkoaPb74Z8hvq1ZnMlnwhRa6c4asjpkVeOsP/Xp1SPObprPpNvSy4M3SE4nPHdfJ0Xl1lfCoyLgfTYj4ReaoK6axcR+QZ/+YMyco1GkilUE9zrsS03QZd3bsOz5VQgtc9Wl+8jPPlfMKlbsRgynUWRanfLvKqD9riIPoSuM6L/g/VzWRC8ml9l7qOHraSxWw84U/ps9Bv61fezI717WxtqqxuPAhZqnFjfM9CqqX+Zduv+okBT6dP1cCqqVVpNc8D3fdiwWVat+/8qt8plmqxRFtd1Xbzeijr3pHqn0fJeb47ayKrxynkdCnU+nKN0u7tvfsaAW2dVuYkz4zG7qvONFCifR7ThCjAQfTd5mH4pPmLehL543uMvOpivkjluqdD508LjO5qk4sX3cFlrsYPspiPRa5tOMOHdFbyLvha5ps0wHHbUSZNYLpRJFHj6Q6zrN95CIH5A8P5A7uAP9z1O8IfFo7wd48jKLlE+QGBItag83vE/F7HSJqxoA1OfzvSzYT14klbwQzbwXwQM8VlRzYygLfchNltRrpHTLE9KdpnKdj2kn9bSF6WAyXTvFwUUg0mfKZaHD9Zz5S3ap+aTaM8TyczPs5EWf39HlTe+iR5mo2f0jyrCKF0p8ra3d6e2PxePzovMr5tFDJTIWz8IY70mzztnY/zo+Nznj9zuZtYjkH+YD9l97Aflc0TGJARes0VbgI4+eHXXG2LJArN2gkGrdgy+ca4aD2IMdBZhevRbrimduE6gqWqBO27ASoOnc51vfee+5vdAgThtkn/yiE8KLK4fRl0vylCoak4glGAeNupmfNMLOcDPtMzIrUvLAqdQlu8YEOCNmvEcjlLPvRydnS8jBb148+sF7u9e1cGCxmEomMGu5KYwQ7PdreHxYwtAO14+UAIkBtGcgGG3VZTX/LKBvylrzVeO0z83QKjmyMqDDSEko34KI0hANsNgEHcR/OSXISXt72JfGAB+Fek5kcMuk0L6P28DYG8DVC8JTVpvS/Be3z8E9L2phExT0pHrM5jWhkFYEHQZCk5DZtpDGQzTh6g51cH7j6GOoDQrQJctmZAoYtEVlB+8OXwKbA0iLck7A/rfjf0PhJ6YKGHxMiNlf8GvfUCZW+zAM1NCcpLo8vnJnpluSkB554AlVsSHMCdRUfPVnAnlxDcCaqICy28Eiuxj55J67MszUAdgNpVHMiPUHUe2e4J2/3N66VsZNhegAUcQ2wHKtyUWau85y1QjI4u8Y4OrEy4RokMLqiZTgc0WvOB8PrWgtxF4a1KG+eV46hh00eD4+oCxORP0MgdWCNMr4jAg9MT2EcKN8ACCQ3tBNdPvRV9ois2RkHXoOV1Si++YfuIdB5isEcNZRyoFEQja2H3o7P/X+xhTqSEAxVuaYwTbs9P/5uPoeAwb3/36kN3zU2sTNrvHt0SHL2hGg9NrHyDfvrG/oQ3lA2wmt8WSo8h3TIPpxd4CNpbyQU3u3IBs5MLoHmHEZvB0zMN3lIrocBDfQx9yuEye6qTHIyy+YwiNpxZMWn30aEKfH9e6cSZ2eJMf06cDcfgGMPVaPBFtv4c0YkzWiQJroTPF/ouykRYFmKKGC05p6s4AtySs8AW0J/0QzcTM1mEAjQBAwoUuRhOY4k+91jgQqQRaGBZ3FCojA0Nde2uWWSF/OV2UORad1Ch7VmXfmTbzxBo2+uvl4c7X0u7ziydcD1+5y89QVWRWff5l3+4Xuzre3rIZf1xm+/TiDAvjr3V6n8q5xV8

OK, finally played with it. Pretty damn sweet! Now we just need to XKnight the shit out of it until it's got a negative number of combinators.