Request (.17): Simple 3-light indicator for item count in a chest

[Losers]

Hello! This is my first post on the forums.
I'm looking for some tips (or blueprints) to the simplest possible single-light (three colours) indicator for chest content amounts.
E.g. 0-33% full = Green
34-66% fill = Yellow
67-100% full = Red

A lot of the creations inside the Combinator Creations seem excessively complex compared to the simple need I have. I simply cannot wrap my head around how these things are supposed to work, and I have tried for hours with the only success being an item counter that leaks its (supposed) reset into the counter itself; making the counter just continue to increase instead of dropping to zero... So close...

So for now I am hoping the forums can be of some more help than my (at this point) useless brain.

Thanks for your time!


(Simply for the sake of mentioning it: The one thing that I did make (almost worked) was not the light indicator at all, by the way. I could never get the lights to work a all due to what I suppose is light priority (or, rather, due to my own limits)... But this other thing that "almost worked" was supposed to be an item counter based off two Inserters: The input inserter was supposed to be active only when signal told it to, then it could input 10 items, and stop as it received a stop signal. The output inserter, as soon as it touched any item, would unlock the input inserter so it could fill up with 10 new items, repeating the loop. I was intending for this to prevent uranium centrifuges from filling up with ~100 uranium-235 (since it's so precious), but instead only insert the required 40, and then stop inserting until the output inserter was starting to eject items; which meant the centrifuge was done and could accept more items to process. An anti-buffer I guess? I don't know what to call this, but it was supposed to free up 235 for other centrifuges to get things going faster. But from all the time it took to try to make this, I now have ~2.5K 235 so the issue is sort of gone simply because there is so much excess now... heh).

[DaveMcW]

The light priority is weird, but you can work with it once you understand it.

Red is first
Green is second
Yellow is third

So the solution is to use a constant combinator to generate an always-on yellow signal. Use decider combinators to generate red or green depending on the item level, and it will overwrite the yellow signal.

[darkfrei]

If the light get all three color signals simultaneously, which one will be enabled?

[Optera]

If the light get all three color signals simultaneously, which one will be enabled?

As with any signals, it'll pick the first in order of internal representation which for base is the order we see in signal overview. With mods however it can be quite different.

[Losers]

This is interesting! Great response, @DaveMcW ! This helps a great deal. Thank you very much. I can definitely work with this.

Are the developers considering adding a single combinator-like machine to combine "elseif" or an "or" function? E.g. to do the "red vs green" within a single machine?

[TruePikachu]

If you use the signal priorities, yeah, the simplest solution is two comparisons and one constant, but there is no guarantee that it will continue to work in the future, and might need to be rewired after changing mods or an update. (That said, it's probably as unlikely as possible that it would break from an update, but it might still be an important concern for some people who use signal-related mods.)

Under the current operations provided by Factorio, and not using signal priorities, the simplest solution I can think of uses three comparisons:

• The chest is wired into the inputs of two combinators
• The output of all three combinators are wired together with one color of wire to the lamp
• The output of the two combinators the chest is wired to is wired together into the input of the third combinator with the other wire color
• The chest-wired combinators handle the conditions where the level is low and high (i.e. not middle)
• The third combinator handles the mid-level case, and is active when neither input is (EVERYTHING=0)

This setup also has the possible advantage of emitting a single control signal depending on the level (the control characteristics include a single tick where either two or zero signals are active during the transition period, which can be fixed by using a fourth possibly-shared combinator as a buffer).

---

To my knowledge, there are no plans to add additional combinator entities, since they would be additional entities. Furthermore, I doubt any operation that independantly considers the states of the two wires would be added; it can already be wired up (using extra combinators), and it could (I'd have to check the implementation) complicate the internal logic (since all operations currently perform an implicit addition).