Add "read belt length" circuit option

[Milichip]

TL;DR
Allow belts to have a checkbox "read total belt length" which outputs to a user-specified signal the amount of belts connected to it (a belt would be considered "connected" in the same way the "Hold (all belts)" considers connections).

Why?
I want to measure item dispensing rates (items / second) and having the length of the belt would allow me to make the designs much more flexible (i.e. not having to count and hardcode the amount of belts in).

(not worth making its own suggestion post for it, but a "read belt speed" that outputs 1 for yellow, 2 for red, 3 for blue and 4 for green, would also be nice to avoid hardcoding stuff in too)

Alternatively, instead of transmitting the belt length, you could transmit the belt capacity. So, 8 for every straight belt, 7 for every curved piece - not sure about splitters, but I assume 4 per side that is read, totaling to 16?

Also, I understand you can make a "maximum" memory cell and flood the belt with items on both sides to measure its capacity, however both filling it like this and doing the cleaning afterwards is a lot of annoyance, and if you ever reduce the belt size you need to clear the memory.

[BlakeMW]

I agree that this would be handy.

[eugenekay]

I want to measure item dispensing rates (items / second)

This is what the Read Contents “Pulse” mode is for - it will send a signal for 1 Tick, for each Item which passes by. You can use this with a “Memory Cell” combinator setup to repeat the “Input Count” onto the same wire (and a 60-Tick reset circuit) to calculate the number of Items per Second.

Good Luck!

[Milichip]

I want to measure item dispensing rates (items / second)

This is what the Read Contents “Pulse” mode is for - it will send a signal for 1 Tick, for each Item which passes by. You can use this with a “Memory Cell” combinator setup to repeat the “Input Count” onto the same wire (and a 60-Tick reset circuit) to calculate the number of Items per Second.

Good Luck!

Yeah, I decided to go with that approach after experimenting with belts vs combinators.
The advantage of belts, however, is that they don't require a memory cell, so they're a lot easier to debug (or rather, a lot less annoying to fix when things go wrong).
However, it still would be a neat feature - especially being able to read the belt's capacity.

[Muche]

Also see / duplicate of Allow belts to output the count of the belts attached that are in read-hold-all-belts.