Hello there. I decided to implement a scheme that will determine that an outpost has depleted by using signals from belts. This is no way an ideal implementation, probably some of you will offer better variants.
empty-belt.png (289.67 KiB) Viewed 13168 times
Here red lamp indicates that belt is empty meaning that resources in outpost have depleted.
The main idea is such: upper (in screenshot) belt unit is sending pulses to the counter, which is been reseted once per N ticks. Upon each couting cycle the signal is passed to AND gates which set or reset a latch.
legend
empty-belt-legend.png (288.13 KiB) Viewed 13168 times
So, if you have and ideas or suggestions on how to improve this scheme - you're welcome to post them here
Re: Resource depletion detector
Posted: Wed Jul 20, 2016 4:53 pm
by Guu
11
Re: Resource depletion detector
Posted: Wed Jul 20, 2016 4:55 pm
by Meelo
I would implement it as follows:
Screen Shot 2016-07-20 at 12.47.21 PM.png (65.39 KiB) Viewed 13102 times
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)
Re: Resource depletion detector
Posted: Wed Jul 20, 2016 6:00 pm
by BlakeMW
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).
even_simpler.jpg (13.29 KiB) Viewed 13074 times
Re: Resource depletion detector
Posted: Wed Jul 20, 2016 6:04 pm
by Amegatron
Meelo wrote:I would implement it as follows:
Screen Shot 2016-07-20 at 12.47.21 PM.png
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)
Thanks for sharing your solution, it looks nice )
Re: Resource depletion detector
Posted: Wed Jul 20, 2016 6:08 pm
by Amegatron
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).
even_simpler.jpg
Yeah, it is pretty the same as Meelo's. Also with addition of 2 another combinators we can prevent integer overflow in the counter.
Re: Resource depletion detector
Posted: Wed Jul 20, 2016 6:40 pm
by siggboy
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.
Re: Resource depletion detector
Posted: Thu Jul 21, 2016 7:14 am
by dee-
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.
Sure, but in this context it not only means your game has been running for at least 414 days straight, it also means you failed to check on your depleted outposts for at least 414 days. I guess you'd deserve a failing circuit for that much negligence .
Re: Resource depletion detector
Posted: Fri Jul 22, 2016 8:53 pm
by Amegatron
So, I've built a prototype for outpost monitor.
Outpost monitor prototype
monitor-prototype.jpg (193.58 KiB) Viewed 12845 times
YELLOW: 4 dummy outposts. Despite it will take more than a year of 24/7 to get an integer overflow, I added 2 combinators to prevent it anyway PURPLE: display with memory-cells. Each cell needs 2 ticks to be rewritten. GREEN: a 2-tick interval clock because of the taken memory cell design. BLUE: outpost data receiver and writer to display.
Re: Resource depletion detector
Posted: Fri Jul 22, 2016 9:50 pm
by siggboy
It can be simplified, depending on how many outposts you want to support.
You can give every outpost a dedicated signal. In 0.13 this has become a lot more viable because we have so many virtual signals now (all the letters and the digits).
If an outpost wants to signal depletion, have it output its signal on the wire. You might end up with something like "A 1; D 1; N 1" on the wire. Then you can give the lamps the corresponding condition, and you're done.
No need for registers and tick generators to facilitate the memory (as exciting as that might be ).
The downside with this approach is that the number of signals is limited, and you can't use them any longer for other purposes on the same wire.
I don't think there's really a good use for the registers unless you use a proper multiplexing protocol, where each outposts pulses out their status successively (and then you store it in the corresponding register on the receiving end). That's only useful if you only want 1 signal for the status; if you have several (one for each outpost), as described above, you can output them permanently (hold signals) because they don't conflict. Registers are then not necessary.
Re: Resource depletion detector
Posted: Fri Jul 22, 2016 9:58 pm
by Amegatron
Sure, that's also possible and maybe even better (I don't think I will have too many outposts in the nearest future ). But for me it was just more interesting to implement it this way I'm slowly moving towards creating my CPU in Factorio.
Re: Resource depletion detector
Posted: Fri Jul 22, 2016 10:10 pm
by siggboy
I think you should try to make a complete multiplexer and demultiplexer; that's very useful and you can apply a lot of interesting techniques.
A CPU (universal computer) is very difficult to create (I have never attempted it). Let us know about your progress.
Re: Resource depletion detector
Posted: Fri Jul 22, 2016 10:23 pm
by Amegatron
I think I need a practical application first to start implementing something. I mean it is not so inspiring to implement something abstract which you don't know what will be usefull for 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 )
Re: Resource depletion detector
Posted: Sat Jul 23, 2016 7:21 am
by Amegatron
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
examples
green.jpg (65.39 KiB) Viewed 12502 times
yellow.jpg (98.78 KiB) Viewed 12502 times
red.jpg (57.69 KiB) Viewed 12502 times
P.S. Also found a bug or maybe a feature? When a circular belt is really full, items stop circling on the belt )
Re: Resource depletion detector
Posted: Sat Jul 23, 2016 9:12 am
by siggboy
Amegatron 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
How about this solution that uses only 4 combinators :
belt-integrator.png (50.73 KiB) Viewed 12498 times
In fact, using "hold mode" is better than pulse mode, because it allows you to "integrate" over the contents of a belt tile (it's what the above circuit does). This also works with a "stalled" belt (= full belt), actually that's the case where it always outputs the highest number -- makes a lot of sense since a stalled belt indicates a healthy outpost.
The circuit takes the content of a belt tile -- in hold mode -- and outputs it to a register. Because the register has a feedback loop, this will integrate over the input values (integrating is really nothing more than a fancy term for "summing up", in a sense).
The sum is output every 60 ticks and the register is cleared 1 tick later. So it always integrates over the past 1 second; the output is something like the "cumulative belt volume" over one second. You can divide this by 60 and you'd get the average belt volume per tick -- which is "8" for a full or stalled belt, and "0" for an empty belt.
In any case, you can use any of these values directly as a measure of how healthy your outpost is (high value = stuffed belt = lotsa ore; low value = not much ore; zero value = outpost dead). It's probably good to sample over a longer period (eg. make the counter wrap at 600 and you'd integrate over 10 seconds).
P.S. Also found a bug or maybe a feature? When a circular belt is really full, items stop circling on the belt )
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.
Re: Resource depletion detector
Posted: Sat Jul 23, 2016 9:52 am
by Amegatron
siggboy wrote:
How about this solution that uses only 4 combinators :
belt-integrator.png
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 counter (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
Re: Resource depletion detector
Posted: Sat Jul 23, 2016 11:08 am
by siggboy
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?
If you divide by the number of ticks that you used to sample (minus 1 to avoid rounding down), you will get a value between 0 (empty belt) and 8 (backed up belt); if the belt is compressed but moving you get a 7. The other values are gradients of this.
You could use these numbers without further processing as a measure of the outpost health, without having to go through another few combinators to create a scale. If you want a coarser scale (e.g. 0, 1, 2, 3 instead of 0 through 8) you simply divide by a higher value.
I think it's easier than doing it all manually.
(BTW I'm counting 19 combinators in that example above. Don't you want to make it smaller? My train scheduler uses fewer combinators than this at the outpost...)
Re: Resource depletion detector
Posted: Sat Jul 23, 2016 11:14 am
by Amegatron
siggboy 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?
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 signal
Re: Resource depletion detector
Posted: Sat Jul 23, 2016 11:25 am
by siggboy
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).
