Factorio Forums

siggboy 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).

Sorry for misunderstanding, my reply was mainly to your comment abount the amount of combinators used 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.

Nice. I will make something similar and integrate it with my train system. I have a few ideas; probably I don't even need to measure the "health" of the outpost. It should be sufficient to measure how much ore the outpost generates while the train is traveling from the main depot to the outpost (yet another way of measuring the same thing). I can also use that number to more precisely call the trains on demand (that's a different topic, however).

By the way I have two more ideas how to measure:

1. You can count how much ore goes into the buffer chests per second/minute, instead of counting at the belt. Then you don't have to deal with problems like stalled belts etc. If you use a balanced loader then you'll have all the chests and inserters wired up anyway.

2. Another idea (not by me) was to measure the amount of electricity used by the mining drills. When the outpost depletes, more and more drills turn off, and that means less power is used. Sadly it's still not possible to measure this directly. The accumulator only outputs the charge amount, not how much energy flows through. There are probably some ways, by cutting off the outpost and count how long it takes for the accus to lose a certain charge.

After participating in another thread (29679), I've made this: Three combinators to measure the belt status, and zero combinators at the main base. The status is reported over the red wire. Each display has the input condition set according to the outpost number (signals "1", "2" and "3" in this example). The values are permanently updated (live), and no polling is required.

Of course one could also use a row of lamps for each that show a status bar, or color coding etc.

Blueprint requires Nixie tubes mod.

Call me pragmatic but a simple depletion detector would work completely without combinators.
The limiting factors are the speed of the miners and the belts.

Belts are set to hold and lamps are set to everything=0
Like so: If the belt is empty the lamp will turn on or trigger an sr-latch. No fancy combinator-magic required

Yea well, at mining outposts all you basically do is put stuff into chests. Why not avaluate the contents. No weird belt magic and needed. Simple ,ORE = 0 -> Output RED light. ???

Brathahn wrote:If the belt is empty the lamp will turn on or trigger an sr-latch. No fancy combinator-magic required ;)

OK, so now you have a light that is burning at your outpost when it is close to depleted. How does that help you determine the status of remote outposts?

You need to transmit the information to the base, and that requires some combinator work (either a simple approach with separate signals, or a more complex approach with polling/multiplexing).

Your "pragmatic solution" is not really that pragmatic when you consider that it doesn't actually help the player :).

aober93 wrote:Yea well, at mining outposts all you basically do is put stuff into chests. Why not avaluate the contents. No weird belt magic and needed. Simple ,ORE = 0 -> Output RED light. ??? :roll:

That's not very helpful, because usually you want to know in advance when an outpost is running low on ore. That's the point of the setup that I've posted above, it will show you numbers, and if these are low it means the outpost is not producing a lot of ore any longer; so it's time to expand.

Most outposts will continue to mine trivial amounts for a long time, but one would consider them "depleted" at this point.

Also, if you simply output "red light" when the chests are empty, this will happen as soon as a train picks up ore (if it does manage to empty the chests in the process). So you might have flashing red lights for your outposts, which might not be considered clean.

(BTW I use "YARM" so I don't have any of these setups.)

I let my trains automatically decide a station with available ore. I don't have any visual confirmation of depletion at this point, but it would be fairly easy I suppose.

Picture of setup:
The method is simply like this:

- All iron ore stations named the same (in my case, 'Iron On'). Copper On for copper etc.
- Wire all chests together, send it to the station, from station to incoming rail signal.
- Rail signal is red when ore in chests are below a certain amount. Trains will prioritize other outposts that have green entry.
- Splitters ensure equal amounts in all four chest sections. Red marked splitters ensure that both sides of the belts are equally utilized, preventing clogs from harvesters
- The station sends amount in chest to train via the station gui. The train is set to leave at a set amount of ore in cargo.


Pros:
- No train will come unless it is guaranteed to leave with the specified amount.
- No waiting time for the train to fill one cargo wagon over the other, as there will always be equal amounts in each of the 4 chest sections due to the way I split it

Cons:
- If no stations have above the specified amount, train will go to any red station and hold until it opens up. Stuck forever if outpost is depleted.

Expanding on the idea, potentially fixes the con:
Make sure you draw power with big electric poles along your rail, so the signal can be carried along with it also. Relay the ore signal all the way back to the main rail, connect it to a rail signal there like in the picture, and do it for all break-off points that go to ore deposits. Put a rail chain signal that will block the entire rail section if none of them has ore available for pickup. When one opens up, a train will immediately go there. EDIT: Or simply rail chain signal to read it at the station without the need to pull the signal that far

I feel this method fixes most of the need for monitoring output, depletion and so on. They just go about their day, while I keep expanding

I like your idea solution I might try it in my current save.

Festmester wrote: Cons:
- If no stations have above the specified amount, train will go to any red station and hold until it opens up. Stuck forever if outpost is depleted.

You could tell the train to wait at the unloading station until circuit condition is X. X=Any station is green.

The thing width telling the train to come when any station is green doesn't work with multiple trains.
I made a setup a while ago that worked the other way around:
the trains sat in the outposts and the furnaces told a train to come depending on how many trains that was ready.
it kept track of the trains that was already on the way, so that it didn't send 10 trains when it only needed one.

and yes: I like to do things 100 times more complicated than they need to be