Factorio Forums

We have a base that covers a large geographic area and keeping repair packs supplied to the roboports along walls is annoying. Since we can't read the count of repair packs in roboports and want to evenly distribute repair packs across the walls we have the following elegant hack.
The design consists of:
* A constant combinator + decider combinator clock that counts from 0 to 18000 (about 5 minutes wall time)
* A requestor chest that requests 100 repair packs and 4 construction bots
* A stack inserter than only runs when the output of the decider combinator is less than 600 (about 10 seconds wall time)

The result of putting one of these next to each robo port that lives along a wall is slowly filling that port with repair packs and construction bots. They clock that keeps the inserter disabled for 97% of the time keeps requester chests closer to the pack production from monopolizing output and acts as a gate on the rate of pack use. As long as a roboport isn't using more than 100 repair packs every 5 minutes we're good.

Blueprint String:

This is really neat, and so simple.

When I see a solution such as this one posted, I often start thinking about alternative approaches.

What you could actually do is to put a throughput counter (simple moving average) at each requester chest, and then only enable the inserter when the throughput into the chest is LOW (not high). It might require a second buffer chest so you get actually pulses when the an item enters the chest.

That means the inserters won't work while the chest is being refilled (i.e. receiving items). When the chest is full, some items will be removed, and as soon as the robots come with more supplies, the inserter will cease operating again.

Or you simply count the inserter activity itself, without a second buffer chest to route items through, and disable it when it has worked a lot on average in the recent past. That would practically put a negative feedback on inserter activity, but on average (smoothed), and it should bias all inserters equally.

It will probably give those inserters that are further away from the supply bias over those close to the source (because the chests closer to the source will get replenished first, and probably have higher throughput/in-flow overall).

I have not tried it in practice, but it could actually work, and basically balance the inserter activity over all roboports. The challenge would be to find appropriate threshold values for the throughput, and set the moving average factor correctly (not too high, not too low).

Such a throughput counter requires only two combinators, so it will be only 1 tile bigger than your current solution.

Edit:

So I've tested it and it works really well. It's basically a chest balancer for disconnected chests. For my test setup I simply put a few roboports at varying distances, with only 10 logibots to limit throughput. Then I limited the throughput of the inserters by putting negative feedback on the inserter (i.e. disable when the throughput is above a threshold).

Result: all the unloading chests receive the EXACT same amount of items over time, no matter how far the respective roboport is from the source. The unloading could be done directly into the roboports, of course, since you do not need to count items.

Requires three combinators per roboport (two for the throughput averaging and one for scaling the values).

Here's a blueprint. Maybe you want to test this approach in your game, as I don't really have a map where I could test it under realistic conditions.

Edit 2:

Thinking a bit more about this, I've realized that what you've build is a simple PWM limiting on the inserter throughput. Your target is 20 units/minute for the inserter, as that appears to be the cap you want to put on repair pack consumption per roboport.

So if you use a Stack Inserter (~1660 units/minute throughput), you'd want to scale this down to 1.2% (not 3%), but obviously such high precision is not required.

Your PWM approach is probably the simplest possible way to achieve it, but of course the granularity is very low, as the PWM pulse only happens every 5 minute. That means that if there's a consumption spike in repair packs, the system cannot really react to it quickly. Again, in practice it probably makes no difference at all, but it's interesting to look at from an academic point of view :).

You could enhance your PWM circuit very easily by making the clock period shorter, and then also use a Fast Inserter instead of a stack inserter for better granularity.

For example, to scale inserter throughput to 2%, you have your clock run through 1,000 (instead of 18,000), and activate when it's below 20 (instead of 600). Then it will trigger every 16.7 seconds for 20 ticks, which is enough time for 1 inserter operation; of course that's 12 items every 17 seconds, because the Stack Inserter moves such large batches. With a Fast Inserter you could scale more precisely, and retain the quick reaction time of at most 17 seconds in this case.

Then of course, you could also simply count the stuff that the inserter moves, disable the inserter when it has reached a count of "20", and reset the counter every minute. That will then be precisely the number you want. Requires one additional combinator for the accumulator though.

My throughput limiter is even more precise, but probably not warranted because the complexity is higher (3 combinators instead of 2).

some interesting (over my head ATM) solutions. i would hope the devs whould make the repair packs in roboports availible on the network in a future update.
me, i just fill them with repair packs and have a requester chest connected to the robo-port that asks for 10 repair packs.

impetus maximus wrote:some interesting (over my head ATM) solutions.

I was rambling way too much in my reply, making it look more complicated than it is.

These solutions are actually really really simple: they limit the amount of items the inserter is allow to move per minute, by disabling the inserter when certain conditions are true.

The two basic approaches to this are:

• You count the items that have been moved, and reset this count back to zero every minute. If your count exceeds a certain limit (say, 100 items), then you disable the inserter. The inserter is then not allowed to move more than 100 items in a minute.
• The other approach is to count the TIME, and only enable the inserter during a certain percentage of the time. That is the solution that edalquist posted.

So it probably just appears to be very complex to you because you're, supposedly, not familiar at all with combinators.

BTW, I think the best solution to move 20 items per minute is to use a Fast Inserter, have the counter loop through 540, and activate the inserter when the counter is equal to any number between 0 and 540 (i.e. it gets activated exactly once every 540 ticks).
The inserters reliably trigger on single-tick pulses, so this will have the inserter move exactly 20 items per minute (assuming a stack size of 3).

Maybe this is a dumb question, but why don't you use requester chest + passive provider chest?
A single inserter between chests with condition "passive provider is empty".
In this case repair packs will be evenly distributed between all roboports, and new repair packs will be delivered to the roboport with fewer repair packs.

Overall it should look like this:
requester chest -> stack inserter -> steel chest -> fast inserter (condition: enable if "passive provider chest is empty") -> passive provider chest.
Also, each steel chest should be connected to its requester chest multiplied by "-1".
Red wire over steel chests (in all roboports) + logistic network content (new repair packs), divided by amount of roboports.
This value should be used in all requester chests (request mode) during lets say 30 ticks every 3000 ticks.

During these 30 ticks each requester chest may request 30 robots, and this means 120 repair packs (so theoretical maximum throughput is 116 repair packs in 3000 ticks).
4 repair packs for this roboport will be taken from its passive provider chest .

Edit: quite interesting stuf, it seems like this build is even able to redistribute repair packs.
For example: one roboport don't have repair packs at all due to biter attack, while free repair packs on the base are not available.
In this case repair packs from the neighbourhood roboports will be taken to this roboport.

"Maybe this is a dumb question but why don't you use [... describes extremely convoluted setup ...]"
-- XKnight 2016

Sometimes you take it too far with assuming that everybody coughs out contraptions like this on cue .

XKnight wrote:Red wire over steel chests (in all roboports)

If you have to draw a red wire bus across all roboports, this is not a disconnected solution anymore (which is the main selling point of the simple "limit inserter throughput" approach).

Your setup is rather awkward to install and maintain, compared to the original design which is just a disconnected, and very simple, roboport blueprint.

Of course if you hide a conventional buffer chest balancer behind all this (which is what you're doing, effectively, if I understand your design correctly), you can have a perfect solution.

Which is not to say that I don't love what you've proposed, it's great.

siggboy wrote:If you have to draw a red wire bus across all roboports, this is not a disconnected solution anymore (which is the main selling point of the simple "limit inserter throughput" approach).

I accept your challenge.

Now it is wireless.
To configure this setup you should select 2 different items that are never used in your logistic network, for example: steel axes (itemA) and wood (itemB).
This setup has 3 different states 0, 1 and 2, each state is the amount of steel axes (unique itemA) in the logistic network:
state 0: at the end of this state all repair packs in roboports should be in their passive providers, so this is an "unloading state". Also total amount of repair packs available in the system will be recorded at the of this state.
state 1: at the end of this state all repair packs should be inside appropriate requester chest (except single stack in passive provider, which is used for defense needs), so this is a "loading state".
state 2: during this state all extra repair packs in system will be redistributed using computed average.
ItemB is used to represent current average value, so you need to manually provide at least 2 * max possible repair packs in system.
Important to mention that passive provider chest always has some repair packs inside regardless the current state.

On the main base player should configure timer by selecting different duration for each state, assuming that S0 should be large enough to empty requester chest using fast inserter, S1 should be large enough to fill requster chest using stack inserter. S2 duration means the amount of items which may be redistributed from the main storage (example, 10 ticks S2 means - 10 * robot cargo size max redistribution rate per roboport). S0 + S1 + S2 should be large enough to afford logistic bot fly between several neighbourhood stations.
Remainder value (inside stack inserter condition) influence redistribution rate between different roboports, so larger remainder value - faster redistribution and bigger overhead (items that are delivered from passive provider into its requester chest).

Also, player should specify the amount of roboports in logistic network inside average unit (alternative way is to add passive provider chest into each ropobort with 1 unique ItemC inside).

For example, in my case S0 = 750, S1 = 200, S2 = 50, so max redistrubition rate is 50*4=200 repair pack per roboport every 1000 ticks (1000 ticks is definitely a very smal value, but I used it because my test roboports are very close).

Edit:

Can you please post a blueprint string of that setup. I would like to look at the implementation details.

siggboy wrote:

impetus maximus wrote:some interesting (over my head ATM) solutions.

So it probably just appears to be very complex to you because you're, supposedly, not familiar at all with combinators.

correct. never used a combinator yet. a good explanation. thanks.

siggboy wrote:"Maybe this is a dumb question but why don't you use [... describes extremely convoluted setup ...]"
-- XKnight 2016

Actually it's not convoluted and I think it's better. Your method to just slow things down might help even out the distribution but it's not efficient and I don't see how it caps the quantities. But I like my method the best because there is barely any logic at all.

My method is to drop a passive provider limited to 1 stack and keep it filled with packs via requestor or directly off the train. Dirt simple and no logic, efficiently keeps 1 stack of repair packs at each stop. If I wanted to reduce that I could simply put 1 wire down and "pack<x" logic on the inserter.
There's no reason to even load them into the roboport, the bots will grab them.

And I've never had such a need to keep the bots populated, but if I did then it would be an inserter directly putting them into the robotport with a "bot<1" filter set. That way bots only in if demand is high enough, tries to always have 1 extra sitting in there. This is how I keep my factory from endlessly churning out robots at the main bot network, it grows only to suit my needs.

Combined with filters on the train cars for 1 stack of each item, this works beautifully to keep packs, ammo, bots, etc distributed at all the train stops. It might not be the most efficient as there end up being stacks of items sitting in cargo, but it's rock solid, simple, and quick to fill a new installation.

AutoMcD wrote:Actually it's not convoluted and I think it's better. Your method to just slow things down might help even out the distribution but it's not efficient and I don't see how it caps the quantities. But I like my method the best because there is barely any logic at all.

My method is to drop a passive provider limited to 1 stack and keep it filled with packs via requestor or directly off the train

Well, you've misunderstood a few things .

First of all, it's not even my solution, I'm not OP to this thread, I don't even use roboports to repair my factory. I was just chiming in and rambling about how the inserters are throughput limited so the roboports are filled at the same rate (no matter how far they are from the repair pack source).

Also, OP didn't use trains to distribute the repair packs. He does have a big factory floor that is walled to the outside, and the walls are lined with roboports which require a slow supply of repair packs, ideally roughly an equal number. The roboports are all eventually to be topped off with pack and even robots.

Again, it's not my factory, I wouldn't do it this way and don't even use robots for that sort of thing.

Fair enough.
Actually a small correction, it appears I always use the 1 stack of repair packs in a provider chest because I can't seem to get the circuit thing to work right when feeding the roboport. But using the bot count on the port does work to keep only a few bots in there.
But if you forget to check the box which is not on by default it will just accumulate as many bots as it will hold.

Can you actually explain what is the reason to not just fill everything up to the limit fast by building some more repair pack factories?
Even if they are unevenly distributed they will just pick up repair pack from other port, no problem.
I just cant understand the purpose of the design....
If it could limit roboport packs in each roboport by say 50, ok its really good, but its going to fill roboports anyway, so why?

I'm pretty sure it does not matter much. Of course, if you distribute the packs more evenly ahead of time, then the reaction time to repair will be a little shorter.

If and how that actually makes a difference in a real game I cannot say. To me it seems overengineering.

However, many people like to overengineer solutions to non-problems in Factorio.

siggboy wrote:However, many people like to overengineer solutions to non-problems in Factorio.

Probably because there is only so much you can do with standard solutions before they become boring. So the creative mind has to come up with grotesque solutions to trivial problems.

afk2minute wrote:Can you actually explain what is the reason to not just fill everything up to the limit fast by building some more repair pack factories?
Even if they are unevenly distributed they will just pick up repair pack from other port, no problem.
I just cant understand the purpose of the design....
If it could limit roboport packs in each roboport by say 50, ok its really good, but its going to fill roboports anyway, so why?

Let's move a little bit forward: repair packs is just an item type and using this build we can evenly distribute any item.

So:
- "something" should be quite expensive (otherwise we will just spam the entire world with this item).
- "something" should be critical for defense, because defense demand is unpredictable. Also, while robots are flying to the neighbourhood roboport you wall should recieve huge damage or even destroyed.

At this moment, nothing in vanila can satysify these requirements because everything is very cheap and defense system is brainless.
But some kind of single-use expensive powerfull weapon (atomic bomb?) against Biter King that spawns rarely and have almost 100% imunity to everything and huge damage... this king might be a real threat for huge bases.
And every new atomic bomb is more expensive than previous one

XKnight wrote:And every new atomic bomb is more expensive than previous one

I'd rather see a huge area of fallout... where you can't go for quite a long time without draining your HP until you eventually die or having other sideeffects on the equipment... and Biters/Spitters that settle there mutating and becoming even stronger than Behemoth Biters or have other unexpected resistances different to the default biters.

That would also put some restrictions on how often you are going to use that... and where you are using it... or you might lock yourself up by surrounding yourself with radioactive wasteland.

It's about conservation. Having more than 10 of these at any station is wasteful.
Repair packs are cheap enough, I don't mind making full stacks. But 4 stacks? They will just sit there. The bots are expensive enough I wouldn't want stacks of them at every port.

Somewhat subject to breaking but much simpler and cheaper system:

Put storage chests everywhere you want to distribute, limit to 2 stacks. Put one repair pack in each one initially. On your repair pack production limit to (# of chests) * 200 - 20 on the logistic system.

Rules:

• Ensure no logistic request is equal to or greater than 200 (or as many as you put in one chest)
• Production must be faster than consumption
• Ideally have spare general storage at all times

What should happen is your logistics bots will prefer the storage chests with repair packs already in them, when a chest reaches two stacks it is considered full so additional packs will be distributed elsewhere. You need to ensure it doesn't completely fill up because I often find I limit items to 200 in the logistic network and I get 204, meaning these extra packs would be moved to your general storage and it would fill up there instead. This is why you subtract 20 from number in network.

This means no chest should be less than 180 repair packs (or 18,000 hp). If you've got an area that could possibly go through this number before being restocked (doubtful) you may want to put another stack in there (add 100 to production limit) or add a closer production of repair packs.

Simple, easy, cheap.