Roboport Robot filter

[TI-89]

See... one of the issue with splitting the network is that... how do you get the supplies needed for repair to the robots in the first place? one big network means that everything is somewhere in the network, even if it isn't at hand. If a robot needs to grab a repair pack... well, currently, the nearest construction robot could be anywhere in the network, with my suggestion the nearest robot would be... in the roboport nearest the chest with the pack in it.

The thing is, this is precisely the aspect of logistics performance which falls upon the player to manage. In a giant network you have anything you could possibly desire available for delivery, but there can be high latency if that thing is not nearby (and even higher if there are also no bots near it). The idea behind splitting the network is that you can control exactly what items are available, and so long as you keep the network reasonably sized the delay in delivery should be low. How you get things into the partitioned network is up to you. I'm not saying that there is no usefulness to your suggestion (or even that I have totally solved this problem myself) but that it eliminates a trade off in how you manage your network construction. And in a game where there are always more resources to be had, there are only trade offs, not absolute "correct" and "incorrect" designs.

I'm aware that sometimes my thoughts come out in a bit of a jumble, and my posts usually end up much longer than intended, but if you bear with me I think you will see the value in my solution. Again, there are limitations, but it's possible to manage the logistics network much more precisely than I have seen anyone else do despite quite a lot of searching for information about how to do so.

Suppose I wanted to create a large, self constructing, solar array; but that I don't want it to overload my network while being constructed. Hypothetically, one unit of such an array might look something like this: http://i.imgur.com/WTYCU6O.png (at 0.1 zoom).

Because I'm still pretty bad at this game, there are several things I didn't account for, like electric poles linking between units, and roboports being too far away to self-construct. So I just placed the roboports/large electric poles manually, and they aren't supplied automatically. But let's pretend just for the sake of discussion that I know what I'm doing.

All of the supplies needed to build this array (including robots!) can be supplied by the main network using just a requester, a provider, and an inserter for each resource (I don't fully understand what is trying to be accomplished by the belt interface but I think it's overengineered). Multiple resources per chest can likely be accomplished with circuit logic, but I haven't gotten to messing around with that yet -- so far I'm at the stage of 'simple but effective.' The interface looks like this: http://i.imgur.com/Dt3D04z.png -- the chest on the right is just storage -> active provider, to drain whatever bots had to pick up during construction, as well as excess construction bots when the job is finished. I did not limit the provider chests except for the bots (which both accept only one stack), so there will be a good sized stockpile available should I choose to expand in the future. In addition, the rate at which goods are made available to the network depends on the request size and inserter used, allowing me to decide how much to prioritize this construction.

In my blueprint, all the roboports empty into active providers. After placing, I manually remove the one on the roboport nearest the provider chests, and add a requester for each type of bot. The inserters read bot statistics and insert if available count falls below a threshold.

Roboport setup

Logistics bot inserter configuration: http://i.imgur.com/awWcgn1.png
Construction bot inserter configuration: http://i.imgur.com/sVQWJ82.png

After placing two units of this blueprint, I dropped a few logistics bots in the network (I think I did 12 -- it wasn't a precise thing) and I started writing this post. When I went back to the game to grab more screenshots, construction had finished: http://i.imgur.com/ifmK6G6.png (note the bot count).

Fluctuating bot count

I only have a few screenshots 'in progress' because mostly I was writing this. But I grabbed a few at the beginning for demonstration.
Initial (it was 12): http://i.imgur.com/UnPCLh0.png
Construction bots added: http://i.imgur.com/tE3thFE.png
etc: http://i.imgur.com/7eROQbg.png
http://i.imgur.com/NFDxUQE.png
peak bot count (of what I saw at least): http://i.imgur.com/HciJfh9.png

The logbots are really only there to bring other bots in and out, which is why I had inserter set to 5. But if you notice count in finished picture it ended up at ~50. This is because they always delivered to either the "loading" roboport or the storage chest by it, and so just docked again. If this were crucial, I could always just add an inserter to an active provider which activates if X > 25 (or whatever number). But the point is, bots are stupid -- they will always dock at the nearest port to their last delivery. By observing where bots end up pooling, and adding drains as necessary, you can manage bot distribution within the current constraints of the game.

Now this usage is kinda cool but not totally relevant to your filter suggestion -- except that it is the same. Case in point, I obviously I had quite a few bots from my main network flying to the interface of these two. To prevent a huge number of bots accumulating here for no reason, I added a 'drain' to the closest roboport. After bots delivered solar panels, etc. they went to dock at the nearest port, which was kept empty (and thus available for docking) by my new drain: http://i.imgur.com/jPQRFmY.png. Obviously it's not actually totally necessary to partition a network just for solar panels, but it did keep congestion/energy cost down by using logistic stack bonus to bring supplies near, and using construction bots only within the new network.

Much of the difficulty in distributing bots efficiently comes not from the game mechanics but from the nature of the problem. The particular distribution of bots which will be best for your network depends entirely on how you choose to construct it and what you choose to transport with it and where you choose to send it and in what quantities. A blueprinted filter setting will not give you an optimal bot distribution unless you have a uniform distribution of requests/deliveries -- which you quite obviously do not because you say your bots are pooling. So even with filters you will find yourself running from port to port tweaking individual settings, which is more micromanagement than I think anyone wants.

I haven't totally gotten rid of pooling in my network either, but I've been trying different methods of reducing it without having to empty every single port into a provider. Some pooling in busy areas is desirable. But strategic placement of "managed" roboports is imo at least as good as filters in managing bot distribution. But they leave much of the process up to the player. You say bots will leave ports that have extras, but how many bots is 'extra?' Do you truly need the same number of bots in all locations or do you have some places that have high turnover (train station) and some that only supply goods (manufacturing area) and some that only receive them (defense network, etc.)? Then there are different ways of moving bots from one network for another. One network could request bots to put on a train and redistribute to other networks, which then bring various goods back to a centralized storage location. Or your train station could receive extra bots when there's a surge of trains, then send them down a belt with ore to be sorted when things slow down (I do this in my factory -- not that it accomplishes anything special, I was just experimenting).

I apologize for writing another novel -- believe it or not I could've included much more info (and I intend to write another reply soon showing one of these 'possibilities').

tl;dr: optimizing bot distribution requires reasoning about where bots will end up based on how you choose to use them -- regardless of the mechanism by which they are distributed. Making redistribution part of internal bot logic will actually reduce player control. The central idea behind bots, to me, is that you cannot control where they go but you can control where they are allowed to stay. That being said, it would be nice if there were options beyond having a port 'empty' or 'full' in a large network. The best workaround I have for having keeping some bots so far is two roboports -- one will fill, at which point bots will start docking in the next one, which gets emptied.

[TI-89]

Ok, I'll try to keep this one short. I made a video so you can see it in action; this is just to describe the set up. Also, this is just a proof of concept, not an actual use case (logistics is pretty unnecessary in vanilla, and thus so are the more interesting uses. I haven't used any mod packs enough to know if/how this could be useful but my main thought is if enemies were made much more difficult and unpredictable it would require varying levels of response.).

Basically, I built a logistics bridge over a lake:

bridge

Which is connected at either end to a much wider area network:

WAN

At one end are the inputs, and a managed roboport:

Network intake

Iron plate input:
Logbot input:
(though there were plenty in storage from when I first built this so these weren't touched for a while)

Roboport config

This port has three levels of response, which will trigger at different levels of network load. I probably should've tweaked the values so it went a bit quicker, but the point is that the higher levels would only trigger if there is sustained demand. Each 'response level' is defined by the speed of the inserter used and the request size of the respective chest, and responds at a different threshold. I didn't want to use combinators, so fast/stack inserter just look at total number of bots.
(Inserter level / request size / inserter enabled condition)
Level 1 (Inserter/50 logibutts/enabled if available bots < 50):
Level 2 (Fast Inserter/200/total bots > 500):
Level 3 (Stack Inserter/600/total bots > 1000):

Then there are three stack inserters that trigger if available bots is g.t. 100. This is just a bit of a hack to prevent lvl 2&3 inserters from loading port when there is no demand. All other roboports are emptied into providers.

At the other end there is an iron plate output:

output

My thought here is that 4 stack inserters is the max speed to empty a chest, but idk if this actually works well. In my test the bottleneck was the network emptying the active provider chests.

Because bots are dumb, those in both networks attempt to take the straight line path over the lake. Those in the WAN then have to deviate to charge. This leads to congestion, which leads to bots traveling further and further backwards to look for a charging port. Then bots get pulled in from further and further away, and thus look for charging even sooner after pick up (because they had less charge at pick up) and performance really begins to degrade. The bridge network maxed out at around 1400 bots, the WAN had ~3500 busy and was still not keeping up. I didn't run it long enough, but eventually these flows stabilize when the WAN has all bots trying to empty the provider chests and manages very low throughput because the charging queues are so backlogged (https://en.wikipedia.org/wiki/Network_c ... e_collapse). I tried to show everything in the video so you can see the settings, and which bots are in which network etc. but I don't expect anyone to watch all the way through. The interesting thing is just how the flows of bots develop over time. Video link: https://www.youtube.com/watch?v=DQVFIxjVEnA

I didn't make this in response to your suggestion, so it's not precisely about bot distribution. Just an example of how bots can be actively managed, and why I think inserters provide interesting mechanics for doing so.

EDIT: also worth note -- the throughput of the bridge network is constrained not by the number of available bots or even charging slots, but by the number of bots that it will put in the air at one time. Generally, this is limited to the capacity of the chest (but not when using active providers. See: http://i.imgur.com/rgA8eGc.png) and so max throughput per chest actually is hard limited by the distance bots have to travel. I could always just add another chest, but again the point is that there are meaningful trade offs between large and small networks. They're just not apparent because bots are currently absurdly strong.
EDIT2: I know I wrote a lot but if anyone actually gets through any of it I'd love some feedback on what I've written. I think the whole logistics system is really cool (and almost game-breakingly powerful) in the way that it currently functions, but it took me ages to figure it all out. And that's with a degree in Computer Science and somewhat of a specialization in networks particularly. Some fine tuning of the mechanics, and a lot more clarity in how it's presented to the player, could have some very interesting late game potential. But I'd like to see that done without losing the feeling of imperfect control as the major limitation of its use. I think it fits really well with the idea of making the most of limited tech, which is basically the essence of factorio.

[BenGoldberg]

Nothing keeps you from usung an inserter to pull robots out of the "wrong" roboport and putting them into a provider chest, to send them to a requester chest in the area you want them, and then insert them into the "right" roboport.