Splitting up robotic networks

[Kratos Aurion]

I like being idle and leaving the work to my logisitic and construction robots - but sometimes, i have items far away in a passive provider chest and a requester chest needs those. So my robots will pass a long, long distance with many charging breaks to deliver those items.
I would prefer having better control of my robots, so I was thinking about how to solve this issue - are there any good solutions yet?

I thought about building small robotic networks, like four roboports in one network with a good amount of robots (~100-300) in it. Then putting a requester chest on the edges of this network, one tile space and a second robotic network. Between those networks a fast/stacked inserter, filling a passive or active provider chest in the second network with needed items from the requester chest. Maybe some circuit logic to stop filling the provider chest when a certain amount of items is in it.

I know, I can transport the items also by belts or trains, but what are solutions, if i want to transport them by robots and still keep control of where my robots are (especially stopping them to travel very large distances)?

[Koub]

FYI, an additional logistic chest is expected with 0.16 : https://www.factorio.com/blog/post/fff-203
This should allow you to create "local" storing areas delivered by robots that will also be able to provide via robots.

[ledow]

Yeah, you don't have much choice.

I have a line that's 1000-roboport-areas long, and it takes about 15 minutes for a robot to traverse it. It still works, robots are still generally around in the intermediate ports to do things like repairs and keep the line safe, but delivery of materials from one end to the other, except for blueprinting, is pretty much out of the question.

You would have to split them, but then blueprinting them wouldn't be fun because they would forever be "just out of range" of being blueprinted unless you stood in the middle with a personal roboport or built a temporary roboport into the blueprint that you remove later (after the next section is built).

To be honest, the chest logic would be the easy bit, after a bit of trial and error to work out what you need to request to keep everything going. And I'm not at all sure that: mine... smelt... robot takes to edge of range... gets dropped into box... gets dropped into next area... bot picks up... drops into outgoing box... etc. etc. etc. would actually be any quicker or more efficient than just letting the bots roam site-wide.

Maybe for yourself, for the bots to reprovision you quickly from a local cache as soon as you step within any area, that would work. For everything else, it's just too many steps and would make things slower and take up more UPS.

[MeduSalem]

From my experience... splitting up Logistic Networks isn't really worth the trouble. You only run into all kinds of problems and you can't freely expand the way you want without having to fear of accidently connecting two seperate networks... which would be a total nightmare (happened to me several times already and I truly hated it). If you really want to do to that then you have to plan out your entire base from the very beginning and hope you will NEVER have to change the layout / location of anything because you simply can't without causing a huge mess.

So if you have one huge centralized base then make it one huge Logistic Network. If you have problems with Bot queues for charging then make the network more dense... place more Roboports in between Roboports... double... triple the amount if necessary. In my dense core parts I have a Roboport every 4 tiles (so very, very dense, otherwise I couldn't sustain 10 000 bots trying to charge in regular intervals).

If you have several distributed departments far away from one another you'd be better off connecting them via Train network to deliver items and spare the bots the travel time.



Also as Koub mentioned the upcoming Logistic Buffer chest will be quite handy in some situations... like holding the items to repair the front line or ammunition for the turrets etc...

But apart from that I wouldn't know what to use the Logistic Buffer Chests for since they still won't solve some of the problems with the Logistic Network.

[Escadin]

FYI, an additional logistic chest is expected with 0.16 : https://www.factorio.com/blog/post/fff-203
This should allow you to create "local" storing areas delivered by robots that will also be able to provide via robots.

That's really something I'm looking forward to but... there are more problems to solve.

Imo, Roboports simply cover too large of an area to allow "for that small, disconnected network". There are 3 problems:
1) The area is a square.
2) There is no way to sepreate construction and logistic.
3) Bots don't care about distance when taking a job.

Unless you have a very large endgame base, chances are you cannot set up a roboport lane along your main bus without connecting to the roboports tasked with maintaining your wall in one way or another. Even if you manage to seperate the logistic part, the construction part will almost always overlap. Then you get that stupid behaviour from robots that travel across the entire factory to repair a wall or place a belt even though there is a local roboport with spare resources or even a player with personal robots nearby. Yeah, you could try to capture more area from the biter but this also means a longer and more expensive wall on top of all the war effort.
There trying to set up a simple connection between your solid fuel plants and the train station or carrying a high tech item up your main bus is a can of worms that causes as many problems as it solves. Not because setting up a network is difficult, but you have to cover so much space you don't want or need and then the entire network goes to shit, working as inefficient as it possibly can.

I wish we had
a) Seperate alternative structures for logistic and construction nets
b) An alternative both which covers a corridor rather than a square.

That would allow me to solve so many problems in an elegant and efficient way without removing the need to solve problems with bots.

[MeduSalem]

Imo, Roboports simply cover too large of an area to allow "for that small, disconnected network". There are 3 problems:
1) The area is a square.
2) There is no way to sepreate construction and logistic.
3) Bots don't care about distance when taking a job..

In my opinion the only real solution to all the existing Logistic Network problems is having multiple Logistic Networks at different frequencies re-using the same roboports.

How that works would be that on a per-Chest-basis you'd decide which Logistic Network(s) the Chest belongs to (like Blue Network, Green Network, Red Network, Yellow Network, etc)... and Bots can only transfer items between Chests that belong to the same network color/frequency.

And there would have to be a Logistic Network window where you can use Sliders to manage the amount of Bots dedicated to each color/frequency.

Then it wouldn't matter anymore how large the coverage of a Roboport is nor that it's a square... because whenever two distinctive networks overlap you could simply use seperate frequencies/colors on the Chests for the networks. That way you could for example seperate in between Logistic and Construction or whatever else you like and you also could effectively limit the working distance of robots by using different frequencies.



But all that said... several of the Devs already stated multiple times all over the forum that they aren't likely to change much about the Logistic Network anymore and that they actually hate whenever they have to touch it in some way and of how every change to it would literally mean worse performance.

I think they pretty much boxed themselves in when it comes to the Logistic Network because of how the code base behind it is probably a stitched together mess from the early days of development with only sporadic stuff patched on-top of what already exists. Hence it never had a proper revisit and therefore isn't really suited for expansions or large modifications without requiring a fundamental rewrite which they aren't willing to do anymore since they are focused on getting the game into a finished state. (If you ask me I also wouldn't want to start to tear things apart to the base again when I'm already about to finish up)

Also I would even be willing to sacrifice the total amount of possible robots per network if they'd perform a little less stupid in return. It's not like the cargo-stacksize of robots couldn't be increased via research to make up/compensate for the lesser amount of total robots. I always wondered why they never considered increasing the maximum possible cargo-stacksize (to transfer lets say... a complete stack in one go) so that people would have to use less robots in the first place which would free up some CPU time to make the logic a little bit more smarter. But then again I don't really know how exactly it internally works so it might not be of any use.

So if I had to take a wild guess then they probably aren't even happy that they have to introduce the Logistic Buffer Chest to alleviate at least some of the problems.



Eventually we will have to live with the way it is.

[Engimage]

In my opinion the only real solution to all the existing Logistic Network problems is having multiple Logistic Networks at different frequencies re-using the same roboports.

How that works would be that on a per-Chest-basis you'd decide which Logistic Network(s) the Chest belongs to (like Blue Network, Green Network, Red Network, Yellow Network, etc)... and Bots can only transfer items between Chests that belong to the same network color/frequency.

That was what I suggested at some point
viewtopic.php?f=6&t=52457&p=307754#p307754

My idea is to introduce "logistic subnetworks". Would work just like VLAN switching.
This idea removes the need of separating roboport networks into different networks but it allows to implement all your needs.

In general - all logistic chests are placed into default VLAN (#1) which would mimic the current behaviour.
However you might assign a specific VLAN to a chest (or even assign several of them which is kinda more complex). When assigned a specific VLAN the chest can only transfer items to this particular VLAN and will not communicate with others.
This VLAN will not interfere with construction bot behaviour and player logistic requests.

[MeduSalem]

That was what I suggested at some point

I guess everyone who isn't a short-timer on the forum eventually suggested it already... or at least expressed some basic ideas of how the problems could be dealt with. I remember suggesting it myself several years ago already.

I bet there are several suggestions about it in the list of frequently suggested ideas:

Logistic Network and Logistic Chest Extensions
Roboport/Logistic Network/Robot Enhancements/Robot Routing/Charging

[Frightning]

I like being idle and leaving the work to my logisitic and construction robots - but sometimes, i have items far away in a passive provider chest and a requester chest needs those. So my robots will pass a long, long distance with many charging breaks to deliver those items.
I would prefer having better control of my robots, so I was thinking about how to solve this issue - are there any good solutions yet?

I thought about building small robotic networks, like four roboports in one network with a good amount of robots (~100-300) in it. Then putting a requester chest on the edges of this network, one tile space and a second robotic network. Between those networks a fast/stacked inserter, filling a passive or active provider chest in the second network with needed items from the requester chest. Maybe some circuit logic to stop filling the provider chest when a certain amount of items is in it.

I know, I can transport the items also by belts or trains, but what are solutions, if i want to transport them by robots and still keep control of where my robots are (especially stopping them to travel very large distances)?

This is why many veteran players do a certain amount of modularization of the various major parts of their base and run trains between them. You can avoid long-travel distance logistics deliveries and instead have your trains handle the long distance moves where applicable. The real art to the modularized approach is deciding how to divide the things you need to make into a sensible, but reasonably small number of major modules+handling the miscellaneous stuff. For instance, it makes sense to put all 3 circuit types in the same major module since the Greens are used for Red and Blue, and Reds are also used in Blue production. It might make to put Modules with circuits, or perhaps as their own thing, depending on the scale of production desired.

Modularization also makes logistics networks more CPU efficient because of the approximately cubic (iirc) growth in cpu demand as a function of logistic network size.