Sorry for misunderstanding, my reply was mainly to your comment abount the amount of combinators usedsiggboy wrote:Yes, but the "integrator" method (with "hold" signal) amounts to the same. It reports how many units have been on the belt tile ON AVERAGE over a period of ticks.
You don't need to know the count of the items, because they all need to pass through that one belt tile that you're monitoring. If you know how many items are ON the tile, on average, you know by corollary how many items have moved through (because the belt is constantly moving, and all items go past that spot; unless the belt is backed up).
Let's say there have been "4 items" on the tile, on average, over the past minute. This means the belt was "half full", if it's a blue belt it would mean about 1200 items/minute (it doesn't matter, because you only need to know it was about half full).
Of course, your method works -- you can count individual items and then divide, but this does not work if the belt is not moving (as you've found out yourself). The "hold" method does cover that case as well.
It's two different methods of measuring throughput; I think the hold method is slightly better. I still don't understand what info your method provides that the integration method doesn't (except for exact counts, but you don't need that if I understand you correctly).
I switched the belt to hold mode without changing the scheme and it worked, I only changed the comparison constants. The half of combinators in my scheme are used to just write a signal to a memory cell Also I like the idea of deviding the amount by a value to scale it down to smth like 0..2/3, so 0 would mean almost depleted source, 1 half-depleted, and 2 - almost full.
