Overlapping logistic areas (colored logistics)

[ssilk]

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'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,

I like the small roboports, too.

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.

[ofca]

Yet again, this is far too complicated and will result in considerable workload IMO. My force-split approach could probably be implemented with very minor code changes even for 0.11.17 (I pretty much expect the code already exists, since multiple logistic networks are already permitted and supported) and only exception would be the fact that drones are not constricted to this split network. Implementation described above seems like a big change that won't be used by many players and should probably be compared to asking for a one-tile belt splitting. You can pretty much achieve the same thing by:

adding a possibility of non-dynamic logistic networks (created by player, not by the game automatically)
adding a "belongs to network x" property to roboport that forces it to belong to (and only to) desired network which consists of one or more roboports that have the same discriminator, which may be color, shape, smell, or alphanumerical string. Setting this property excludes the roboport from main logistic network only (construction isn't affected, nor the flow of drones between connected ports)
adding a "belongs to network x" property to logistic chests that forces it to belong to (and only to) desired network which is served by one or more roboports. If only non-default-network roboport exists in the area, then all chests are auto-set to only network available in the area, so no additional clicking on chests -- simple beyond measure!
to keep things simple, and to add a cost to the player for maintaining different networks, chests and roboports cannot belong to multiple networks, even though I think this wouldn't be problematic - but I like the concept of having two boxes with smart inserter between them to move stuff between networks - this adds a cost of work, space and power for the convenience - and additional reward for making things work by yourself

Obviously there is a quick and easy possibility to expand this by assigning drone to specific network, or assigning amount of bots (by absolute value or percentage) to specific logistics network, but somehow I don't feel that this is needed - but this also wouldn't be too much work; that being said, I believe game does quite a good job of assigning drones to tasks and "make more drones" approach solves understaffing problems

That's my 0.03 USD.

[ssilk]

Hmmm. I thought a lot, if and when yes, what to answer. Because my position as moderator makes it double difficult and it is really hard to keep a position, that is as neutral as possible. But I think I need to.

First: I hope this goes not into an total off-topic discussion. I will not answer to any discussion into that direction, cause my target is not to make your suggestion (or others) look bad. My target is to bring the game further.

Short rhetoric question: Do you measure the quality of a suggestion by the change needed? Why? That was never an issue in all the work the devs did. If they decided to do something, they did it.
And it's quite questionable to state "my suggestion needs less changes". You cannot know that. I can also go so far and state now the opposite, cause I can , cause the basics of overlaying robotic networks is already in the code, but splitting is not. I can even prove that, cause I have access to the source. But that is also more guessing, than really knowing.

But I need to say it, cause when I comment a suggestion, I really try a lot more to prove my position, cause I think nobody likes to be told "No, this is a bad suggestion, mine is much better"... (as said, this is even more difficult as moderator) I really try to argument and I think I can say in most cases I have good reasons to do that.


Now to the content. I will not answer your pro-arguments. That would be stupid.

But, yeah, you may be right.

Maybe it's not used a lot, maybe it's complicated. But when it is used, it is quite useful, because it has several usages, not only one. My suggestion covers a lot of issues, the players posted in the last months, mainly things with the logistic network, but also stuff like "how can I limit the robots in my network?" "Is it possible to bring the robots to the place, where I need it", and half a dozen more.

Maybe your suggestion is really better. I believe both directions make eventually much sense. There is nothing, which disjuncts them! In fact I was inspired by yours to write this down, what I moved in my mind since some weeks.

Hard argument: You forget, that roboports needs power. And if they have no power, their network just disappears. What should be done in the meanwhile? Nothing of course, but what kind of nothing? There are edge cases, when some are still powered, others not. What should be done, when they are powered up again? What If you just want to delete the border between two networks, what will happen then? What, if you add a new roboport? How do you split the networks when your network is 500 tiles long? And a doozen of those questions more. There are several edge cases in your suggestion, which are not thought.

I tried hard to think into every edge case I know. I can say this suggestion would work without adding much more than described. [Ok, the current state of that suggestion is not finished, cause the handling with the roboports is not good yet, but this is not a big issue for a suggestion, cause the devs always made that part better than described and there are things, I cannot know yet, so that it don't makes sense to think much deeper into that.]

I bring also a "weak argument": I still played with the small roboports (see mods), which enable to create such limited areas much better then yet, and I played some hundred hours with them. I think they are useful and should be in the game, and I think their usage as "easier splitting networks" behaviour can be really compared to your suggestion (that was the point, where I quoted Shirkit). But my current thinking to this is: I don't like them. It was was always an ugly solution for me to place two chests with an inserter between them. It feels... like a makeshift solution. And to prove that: I even suggested that more or less by myself: https://forums.factorio.com/forum/vie ... ion#p18749
That is now exactly one year ago. So long takes it, to make "good" suggestions.

The solution with such "borders" is wired, but ok. Provisional. Now when I think how that would work with your borders instead, that I can place, I think this isn't that much better to make it worth the afford. Sorry, but I cannot explain it better: There is already a working solution for that case. There are for example also solutions, which propose to be able to change the roboport area, which is basically also the same. And I think one or two more suggestions into that direction (making borders between logistic areas), but I really was not able to find them. The argument against them was always: "We have there mini-roboports" or "look, there is the idea of colored logistics, which feels much better". That are good reasons in my opinion.

But that is not the point, why I was a bit astonished. I know, that my suggestion has only a very, very low chance to make it into the game. But the past shows, that suggestions lead to other suggestions, which lead to other suggestions. See the link above. And sometimes we have pearls, cause someone found a really good and elegant solution. This suggestion is to make others think about this "problem".

And to finish that: If you want to discuss this there are two or three things I want to see:
a) Improve my suggestion, imrpove the weak points or discuss them or
b) bring a good argument to vote it down. Such a good argument is for example: "Do we really need to split logistic networks?" That is still not completely clear to me, in end-effect this is a "nice to have" suggestion. I wrote it in the first post, that I was nearly at the point, where I forgot it. But in the end I thought it might be really useful.
c) make a counter suggestion.

Again: I will not answer to any discussion into that direction, cause my target is not to make your suggestion (or others) look bad. My target is to bring the game further.

[ofca]

Hey, we are just talking here - whatever comes of this is a better game for everyone. And I still will stand by what I said: my idea will be easier to implement and only because it's simpler, and any good programmer will tell you, that KISS is a golden rule of all ages :>

But on-topic: power. It's only logistic network that's split, so drones will charge up somewhere else and chests don't need power, so drones will keep servicing the network normally if they can reach the physical area (i.e. if any other powered roboport covers the same area) - but something else may happen; the network may just effectively go down and no goods traffic may happen. That's up for discussion I guess - and no, I didn't forget. I even went as far as to make it into a good gameplay point, that more roboports = more power = more upkeep for running separate networks.

As to splitting a network - there's nothing to split. Network is just a string of characters. If there are roboports in it, it exists. If not, then it doesn't. If you add a new roboport, it expands - if you remove a roboport from it, it shrinks. The only cornercase are chests - what to do with them when new network appers? Remove them from default and add them to the one you've just created?

As to the inserter between chests idea, as I said - I was thinking that it's a good "penalty" for multiple networks. I don't think that chest being in multiple networks will cause much of a headache. At worst it will take drones two trips - one to deliver from A to B (local traffic) and then from B to somewhere_else (inter-network traffic). Still, that's a one-tile belt-splitter to me.

If you decide to clean up your post from your internal moderator-user conflicts, I will gladly brainstorm with you some more. But please, stop with colors. Colors won't scale. I see colors as an added descriptor for a player-created static network that will be used as font color and as marker (background for area) color on a minimap - and some dev input would be great here, as it's their game and we can't possibly now (or at least I can't ) whether this should be "free" for player, or should it cost player some effort to create such a network (i.e. multiple ports, multiple chests connected with inserters).

And my main point against your suggestion is merely use of colors which are in my opinion insufficient as a primary key for a network

[SHiRKiT]

What you guys are suggesting is exactly what needs to happen. I've suggested this as well a long time ago, and I remember seeing ssilk also talking about this more than one time already (not with this name but ok).

Here we have just the concept of what it seems a good idea. We don't know if it's doable or not, but I feel that it is. The devs may even half have part of the code to separate the logistics networks, since there may already be more than one that works independent from each other.

The downside of this idea is that adds complexity to the game, whereas some users may have trouble understanding it, others will never use it (but this is reality with any feature in the game anyway). The way I can think of is to hide this under a research, and previous to that have everything on default. So that won't change current experience, but will add new one.

Another thing is that we could do this as a mod, but we would need some interfaces for this to work, and some variables/functions to be exposed. I could totally live with that as well. Reduces work from the devs and we still get our feature =]

But IMO, I stick with ssilk's version. It's the EXACTLY same idea I had in mind.

Edit: I think you should link the topics linked in the post [ https://forums.factorio.com/forum/vie ... tic#p38564 ] also here, just for the sake of seeing that this idea has came up multiple times through time.

[katyal]

The mods that having an independant overlapping logistic network would enable is just mind boggling especially if the bots can remain hidden

[ssilk]

@ofca: I still think, that just splitting areas into smaller zones is not enough. That is the important part of this suggestion, it is about overlapping areas. And I repeat, that it is not important, if we use names or colors or whatever to distinct networks. There are enough possibilities, to make them distinct. That is not the problem.

Scaling of colors is also not needed, cause we don't need much of them. But some of what you said is right. I thought about it and I think the complexity is really too hard.

I thought how to make that easier and I think I suggest it now like so:


Forget all about the layer idea, they don't need to be assigned to the roboports.

Assume, that the networks are just player names, like the train stops. You need to define a network, before you can use it. You do this by crafting a new logistic network-entity, anywhere, place it, power it, and it's name is "FreeER " for example. Any other player can use it now. There is not more needed, maybe a color (one of eight default colors), maybe an icon. All of that can then be changed by the player, like with the train stop yet.
Then you can configure the "behavior" of that network, what types of requests are processed, just like with the train, when you are near enough. That was part I.

Part II is then to assign the entities to these networks. In your inventory you have an item, like a defined blueprint. Select all objects you want with it and that defines the networks, they should be in. Select it again deselects. Every roboport and chests can be in up to 3 (or 4? see down about default network) networks. To display the belonging to a network, a flag, or something good distinctable (color, icon, see network definition) are shown besides the entity (for example like with the blueprint: a small icon, that represents this network).

That's it. The robots then begin to work in this network like defined.

In other words: as long, as you have a roboport, which covers any logistic area, you can assign logistic chests to any "layer" that is defined anywhere. And there is still the default layer, see down. No layers, no different colors. Just small icons besides the entities you want to have in different networks.

@SHiRKiT: That kind of feedback is what I wanted. Yes, the complexity it adds is an issue. And again, is this really, really needed? Or is a simpler model, non-overlapping, like that with the limited areas/domains more useful? There is already some code in the game to handle overlapping areas, but I think the devs do also not really know, what direction they want to go.

@katyal: Good point.
That was, where I changed this suggestion like above.

I think we still have the default logistic network (one network for every distincted/splitted area) and are also not connected, like the above networks. I admit, this part is not fully thought through, cause where do I define the number of bots that should work for that area and other questions I don't know yet?
But this is, how I currently think it: An logistic chest/roboport has the the current logistic network as default. Or in any case we have a default layer (the current logistic layer, that can be switched of for selected entities). That would keep such mods running.

[SHiRKiT]

Well, either way, they try to solve the same problem with different approaches, but it's mostly the same result. I agree that the second suggestion is really cool, and even better, but needs somehow to be presented easier to the player.

- If the item should be held on the hotbar, then somehow we need to see which entities belong to which network, and this would be a hassle. This is not easy problem to be solved with this standard.
- Also, only a few entities actually belong to the network: smart inserter, chests and roboports. Robots would only fill the request made by those networks.
- We should be able to see to which network each of those entities belong when we click on them (open it's GUI).

This issue is removed with colored networks, although they are not as powerful as this idea, but it doesn't come with this visualization issue (maybe someone else can help me on how this could be done without making the user confused).

[ssilk]

Well, either way, they try to solve the same problem with different approaches, but it's mostly the same result. I agree that the second suggestion is really cool, and even better, but needs somehow to be presented easier to the player.

That is really difficult, I made me yesterday several drawings, that showed me, that the functionality is difficult to display.

But it was good to make the pics, cause it showed me also, that it is not needed to tell the Roboports, in which networks they are! That is not needed. You need to tell that only to the logistic chests, nothing else. First it was an astonishing thought, but now I think it will make things much, much easier, cause - when you think about where you need this, then you see, that it should not dependend on the covered area of the roboports. There needs to be just some roboport.

I think this was the tweak I need to do in my brain:
There is a strong difference between the logistic area and the logistic networks. the area is the physically covered area of the connected roboports. The network is something more or less virtual.

The default logistic network is just exactly the logistic area. It is locally limited to the area covered by the roboports. Like now.
There is no difference in behavior, if you just use only that. If I connect two logistic areas it is one bigger area. Like now.

The "new" overlapping logistic networks can include logistic entities in many different areas. This shares their statistics, the number of items in them. And some more. But items between two entities in one logistic network can be exchanged only, if they are in the same area. I cannot exchange items between two logistic areas. There is simply no way between them, that the robots can fly. Like now.

- If the item should be held on the hotbar, then somehow we need to see which entities belong to which network, and this would be a hassle. This is not easy problem to be solved with this standard.

I think to filter options. There are already many ideas about filtering for example the bots, or other layers like underground, so why not also chest/Inserters belonging to one logistic network. The switching should be of course easy and you see the selected layer enhanced and all other logistic entities (not in the network) are a bit ghosted. Some fine tuning needed, but without question it's possible, and used in many other games. See for example Rollercoaster Tycoon.

- Also, only a few entities actually belong to the network: smart inserter, chests and roboports. Robots would only fill the request made by those networks.

With this new addition (see above), only the logistic chests belong to such a network. The smart inserters can belong to all networks if covered by a roboport. For each logistic network there is - according to now - just one more line for each logistic network.

Yes, roboports make the communication and robots just fulfill the requests. I even don't need to say how many robots should be in which logistic network. Cause the robots belong to the robotic area, and not to a logistic network. The roboports take care, that the robots in one logistic area are equally distributed. They may take into account, that there are points, where more robots are needed (they have some kind of usage statistics and can estimate the average need of robots within their port area (which would also enable us to put the right number of robots into the area)).

- We should be able to see to which network each of those entities belong when we click on them (open it's GUI).

I think one layer can show me all connected objects for one network with staggered lines. Like the staggered lines for roboports, but for the chests only, so that I can see, which way a robot may take.

You need to think a bit about the usage case, then you see, that this is not enough, but good enough for a first version, which we can play with and see, what's missing.

Well, I feel, like this suggestion is now really good; the only problem is to make it so, that everyone can understand it. I keep trying to make some drawings.

[ofca]

Sorry for long time it took me to get back here. Work, life, stuff

Anyway,

ssilk, I never suggested that two or more networks couldn't exist at the same physical tile. Actually that's the core behind my idea: that there are multiple networks along the default core network, but you need another roboport to create other networks -- this is merely to give additional network a cost, and it's not a necessity.

Scaling: you may not need it, I may not need it, but in a year, 20 players playing on 100k x 100k map may need more than 8 base colors
And yes, your idea with network-creating entity is much more to my liking, but I still feel that power-draining and space consuming roboport seems like a good penalty for multiple networks.

And I still insist, that entities belonging to more than one network are making things too easy.

To summarize: non-overlapping networks are useless. Waste of time in implementing such a pokemon, and I never seen anyone suggesting it. By splitting I meant splitting off from main/default network, i.e. no goods traffic between networks, not physical terrain splitting.

And again, you don't need to do anything more than in my first post in this thread to get full functionality. I don't know where did you get the idea that networks cannot overlap, but that was never my intention

[ssilk]

Sorry of ofca, but the whole suggestion has changed a lot and I made a new suggestion out of it: https://forums.factorio.com/forum/vie ... f=6&t=8905

Edit: please, if you criticize it, would you also be so kind to make a better suggestion, cause it's easy to say something is unuseable, but difficult to say why exactly and much more difficult to make it better.

Edit 2: I come to the idea of separated networks, cause of the first post in your thread:

I would like to split logistics network into smaller zones, in such a way that drones don't transport goods between this and other zones.

[ofca]

Hehe, sorry for the confusion then. I meant splitting the inter-network transport, i.e. goods flowing through the network, not the territorial coverage

[ssilk]

I closed it, see above for reason.