Thanks for sharing your solution, it looks nice )Meelo wrote:I would implement it as follows: The belt is set to read in "hold" mode. Both deciders have their condition set to (stone) < 1 and are connected by green wire to the belt. The top combinator outputs 1 on red if it's true, and the bottom combinator outputs the input count on red if true. Thus, the red signal on the red wire counts the number of ticks since a stone was seen on the belt. Then, we just hook the light up to see if this is more than, say, 600, meaning 10 seconds have passed since the last stone passed through. One could add a latch to this, but if we do see another stone after the light switches on, that might contradict our hypothesis that the base was dead. (I suppose the setup will eventual have an integer overflow if you run it for way too long, but that could be fixed with a couple combinators outputting -1 on red if the count on red is at least 600 - that would also stop it from constantly updating)
Yeah, it is pretty the same as Meelo's. Also with addition of 2 another combinators we can prevent integer overflow in the counter.BlakeMW wrote:Can be done even easier:
Use a decider combinator with:
In: Stone = 0
Output: Each
Wire the input to the output.
This pattern is a counter which counts every signal except the "reset" signal which in this case is "stone".
Use a constant combinator to send a signal like "Red=1", and Red will be the number of ticks since a stone was seen (as such this setup is designed to be used with "read belt contents: hold" so it doesn't show a stalled belt as empty).
Well...siggboy wrote:Integer overflow will take 414 calendar days, if the game runs 24/7 at 60 UPS. It's nothing one should ever be worried about.
.).). But for me it was just more interesting to implement it this way I'm slowly moving towards creating my CPU in Factorio. I have basic knowledge of what (de)multiplexer is in electronics, but can't imagine what will be its interpretation in Factorio right now At least my scheme can also be interpreted as some kind of (de)multiplexing when interrogating outposts (multiplexing) and then wrting to display (demultiplexing) (as I understand it )
How about this solution that uses only 4 combinatorsAmegatron wrote:Now I continued my first variant which uses pulses from belt, because it allows me to count how many items pass per time interval and thus allows to detect different states of an outpost: fully functional / partially depleted / depleted. The only thing I could not beat this time is a stalled belt, unfortunately. Or at least without adding tons of new combinators
:
I think that's a consequence of how the game optimizes belt movement (to improve UPS). An item can only move if the item in front of it moves first (so the game does not have to check movement for the entire belt all the time); a full circular belt is like a backed up belt, because the item "in front" never moves, some item would have to move "first" but it's not possible because it's a circle. I hope that makes sense.P.S. Also found a bug or maybe a feature? When a circular belt is really full, items stop circling on the belt )
Well, it is pretty the same that I have (upper 4 comb-s in my scheme). Everything else is the logic to output and remember the result singnal based on values, collected by the countersiggboy wrote: How about this solution that uses only 4 combinators
(If X > 70, If X > 30 AND X <71, If X < 31). Though belt in "hold" mode cat be easier used to determine stalled belt, it is harder to distinguish other states, because belt contents is "multiplied" by the clock-interval, but that's the matter of fine-tuning those constants in deciding logic The circuit tells me some amount of items have passed through it for the last N seconds. But later I need to determine is it much or not, so there are 3 states: fully or almost fully loaded belt (> 1700 count for red belt for 300 ticks, e.g.), partially loaded belt (count between 700 and 1700 for the same 300 ticks), and almost to empty belt (< 700). So, upon each clock reset I compare the counter to those constants to output needed signalsiggboy wrote:What other states do you need to distinguish?
The circuit tells you how many items are on the belt tile on average. So it's a direct measure for how "dense" the belt is; this pretty much exactly corresponds to the current mining rate. Is this not what you're trying to report?
