, computers.
I guess it doesn't help to count a resource flowing through with a single combinator per chest. But, what you've shown is perfect when what you want to do, instead, or in addition, is to keep a running total of the quantity buffered inside the chests. Also, it's potentially quite convenient that if we chain them like:JasonC wrote:You can do this with one combinator if you don't mind having to use both red and green for the output with the implicit summing. It's combinator A from the OP. Consider the following crappy ASCII art:golfmiketango wrote:Anyone got an idea for how to output a single tick of output when a signal goes from 0->1, and stay quiet until we go back to zero and then back to one, again, with a single combinator?
The sum of R+G on the right will always be the change in the input in the last tick. So for your case, when IN goes from 0->1, the R+G will momentarily be 1. When IN goes from 1->0, R+G will momentarily be -1. So if you can make your circuit work with this logic, you can use it as an edge detector. For example, if you attach both red and green to a lamp, and set the lamp to anything > 0, then the lamp will flash for 1 tick when IN increases (i.e. 0->1) but not when it stays the same or decreases:Code: Select all
/-------------------------\ | | | +-------------------+ | IN---o->R | \----->R | each * -1 => each | | G-------->G +-------------------+
If you set the lamp to any < 0, it'll flash on the falling edge instead. (Unfortunately you can't really get both edges at once with this circuit since there's no not-equal operator in circuit conditions).Code: Select all
/-------------------------\ | | | +-------------------+ | +--------------------+ IN---o->R | \----->R | | each * -1 => each | | lamp, any > 0 | | G-------->G | +-------------------+ +--------------------+
Note that this combinator doesn't behave exactly as you describe, since it outputs a value on both 0->1 and 1->0, but by using >0 on the next element in the series, you filter out the 1->0 case and effectively achieve what you're going for. Still, it's not quite perfect, if you're running the output to e.g. a counter you might not get what you want. But it's the closest you can get with just one combinator as long as your receiver can filter with a condition (otherwise you have no choice but to run it through a >0 decider, thus using two combinators).
In general, though, just remember that since the game implicitly sums red + green on inputs, you basically get a free combinator-less addition that can sometimes help you.
Hope that helps.
[ first order derivative combinator ] -> [ high-pass filter combinator ]
(in other words, exactly as pictured in combinators "A" and "B" of your OP), I can accomplish both by wire-summing signals from the middle of the chain into a "buffered storage count accumulator" and wire-summing signals from the filtered end into an "in-flow count accumulator" (like combinator "C" in OP). If I were buffering meaningful quantities rather than working with just one item at a time, (i.e.: a similar device that pulled from chests rather than belts and thus expected an unpredictable number of items to wind up in the chests), I could then calculate exact cumulative throughput by taking the difference, which is pretty sexy. However for purposes of my "belt counter" thingy, it's probably acceptable to ignore buffering.
