Edit: Please don't read this and the next 4 posts and continue reading here, cause I changed my mind a bit!
We have this discussion thread here: Roboport domains
Originally this was the answer to one post, but I found it worth enough to make it an own suggestion.
I need to go back a little bit and try to explain this:
I like the small roboports, too.SHiRKiT wrote in that thread wrote:I've been smashing asking for colored logistics for quite a while. The solution I found was to create a modded version of a roboport that has a smaller radius,
But what I thought that would be really, really useful, and what made me to follow the idea of "colored logistics" was, that I can overlap the logistic areas. This is currently not possible, but I mean, that would be quite useful.
This resulted in the idea of "layers of logistic networks", which also can be described simplier as "colored logistic areas". That was the original idea behind that. It doesn't mean, that there are really colors, but the picture of this concept is then really easy understandable. And I still like this picture and for this concept it really doesn't play any role, if we name the networks, or color them (colorblinds are a good point, which speaks against that), of have special roboports or whatever. I leave this really open here.
But it was always a weak point, that I couldn't really point out, why this "layering of logistic networks" would be so super useful. Maybe it's meanwhile a bit outdated? Cause we have different needs and there are also other ideas... I was at a point to give this up.
But this morning or so I knewed suddenly, why. Someone posted it anyhwere about a week ago (I didn't find it with a fast search yet, it really doesn't matter). That idea was, to have different abilities of thelogistic bots in one network.
The idea I currently follow is about like so (I try to avoid "colored"):
Concept
- You can have up to 3 (maybe 4) overlapping networks in one area (= three "colors" or names or layers - it really doesn't matter much, how we name it); I already said: They can overlap!
- Each network can have it's own set of functions switched on/off. This means: You can shrink/change the ability to send tasks into the logistic network for each network seperatly. (I really tried now to find that post, but it hides for me). We have this already: The construction network and the logistic network are just two connected robotic networks with different abilities.
- You don't need to set up for each network one roboport. The roboports know to which networks does they belong. This means: They share the amounts of robots for each network and try to distribute the robots in a way, how configured. The ownership of a bot to a network can only be changed, if he is in the roboport, the rest is automatic, nothing which should be micromanaged much, the control for that should be really simple.
- A network knows not only the tasks it can do, it knows also the number of robots, that should be available/max. useable for each network.
Sound quite abstract, I make a
Concrete example
Let's have a big area plastered with roboports. We configured them to belong to these 3 networks depending on position:
- some small networks, call them "production" (and give them an orange color for example ), that do the "normal jobs" like transport of items from provider to requester chests. They can do literally everthing; they act like known.
- smaller/longer networks, call them "transport", that are only able to take from storage chests to requester or from provider chest to storage chests. Good for example to transport stuff from a train station to a "production" network.
- one really big "repair&construction network" , which is also able to "take" from storage and passive provider and put into storage chests.
So this is how it works:
After placing roboports I can configure the networks, they should belong to (for one and many). A network configuration is some global available thing: One name/color is one configuration. I can so configure areas of different overlapping areas, up to 3 types can overlap in one position
In this concrete case the transport network brings the items from the trains to transport belts or directly into the covered production networks.
The production areas are just small (and becaus of that quite effective) areas, which take items from chests, put them into requester for production and after crafting back into other chests for the next transport network. Global config means also: Even if you have splitted networks, they share the same logistic network, if the have the same name/color, and so the same number of items in the network. This is also a cool way to communicate with "light-speed" and without laying wires. So what is inserted in one production network can be seen in any with the same name/color. This is cool.
The repair&construction network takes repair packs from distributed chests, which are filled by the transport networks to enable fast repair and construction. It needs to have one connectin to a "normal" logistic network, I mean it must share chests, that are either in the production or transport network, or filled in other ways. Some special idea for that: Maybe for the construction network the bots can TAKE from a requester chest, maybe this is a special case? Or we have a new type of chest for that?
TL;DR: "Colored logistics" is for me just a name for a cool concept, which is not yet finished. I think this post includes some ideas into that direction. What makes it really cool is, that it could have several really useful usages.
Main poinst are:
- The logistic networks can overlap. Well, the topic says it already...
- Each network can have own "abilities". Only a shrinked subset of logistic requests are executed then. This enables to have networks with different targets. This is the same as with construction- and logistic network!
- There must be no roboport for each network, one roboport can be member of (up to 3?) networks.
- The same networks (same name, same color?) are "globally connected". That enables to communicate over long distances, without need to wire.