Overlapping Logistic Network II

[ssilk]

Sorry, but the rules say new idea, new thread. Good reasons, cause otherwise nobody knows what has been really discussed (as this already happened in the former thread).

This suggestion comes from https://forums.factorio.com/forum/vie ... f=6&t=8849 but has changed a lot since then. The basic idea is about in this post: https://forums.factorio.com/forum/vie ... 849#p70864

But also many other ideas flow into it, namely the former discussion with SHiRKiT and ofca (and his suggestion https://forums.factorio.com/forum/vie ... f=6&t=8843 )

New important concept
There is an important distinction between
A) the logistic area (the area - or should we name that better zone? - covered by a connected net of roboports),
B) the logistic network, that is currently equal to the area. This is also the default network.

Needed research
I think that should be mirrored also in the research: first you have
- logistic areas (which is exactly the same as now but a different name),
- then overlapping logistic networks (this is new and comes from the mentioned post),
- then exchange between the networks (this is completely new and described below).

Behavior
Without this extension nothing changes. The default logistic network is just exactly the logistic area. It is locally limited to the area covered by the roboports, so physically bounded to their placement. 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. The networks are just a concept, or "wireless channels".
This means: 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.

Adding new networks
You need to define a network, before you can use it. To have more networks it is simply added: a globally accessible requester for all players. Press "+", new network is created.
Assume, that the networks are just player names, like the train stops. There is not more needed, maybe a color (only some are needed), maybe an icon. All of that can then be changed by the player, like with the train stop yet.

(Edit: I left out the binding of a network to a device, as in the former suggestion, cause I think, that would make problems, when not powered etc. not sure about this, but also no problem to change that)

Configuring networks
Only logistic chests can then be in more than one network.
There is no need to configure roboports, because they belong to the area. Also the robots.

With the research of logistic networks (see above !), we are able to change the logistic chests network. Just open a chest and select it's network. A chest can be only in one network.
A good idea would be, to have the possibility to change many chest (some select tool needed).

With the research of logistic exchange we can advance that.
We can create combinations of requester and provider, storage and requester or storage and provider.

My first idea about that was to place the needed numbers of chests like now and with some tool or because placed around a new special device, they work, as if they are one big chest, but hang in several networks.

Edit: When I interpret ofca's comment (https://forums.factorio.com/forum/vie ... 849#p70475) then this connecting special device is nothing than a new type of smart inserter, that "virtually connects" the chests.

This part of the idea is not fully worked out yet.

Configuring of smart devices
Smart inserters simply "see" all networks - like now if they are placed in a logistic area, it's just one more row for each network (alphabetic sorted?) in the smart Inserter config setup - but uses it only, if you configure that.

Viewing the networks
No need for layered colors anymore. 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.
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.

Placing of robots
Roboports make the communication inside of an connected logistic area 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)).

Conclusion
Some changes still needed, but generally this has a flat learning curve and the complexity is only needed, when you use it. It doesn't change existing behavior, it doesn't need colors. It needs only to add a new concept, which is already visible. For me this feels, like it was already planned into the game by the devs.

[SHiRKiT]

Okay, I love this concept. I think it pretty much reached the best idea right now. It's fine tuned and polished (as an idea). Maybe the devs see this, they instead of making this, just enabling us to create a mod to do this would solve things as well (although I don't know if this is possible). Like it would be a dream coming true to see this implemented. On my current campaign I gave up on making 1k-2k robots and having everything besides basic resources and massive intermediate (ores, liquids, plates, coil) being moved medium distances with express belts.

-----------------------------------

But I'll leave this comment here, with a note: I'm just posting it here for the sake of if ssilk's idea (which is better) is too hard to be implemented for some reason, there are simpler alternatives that also exists.

+ Roboports when placed are all from an specific color (i.e. orange).
+ Players can configure roboports colors on it's GUI
+ Robots from a robotport color (e.g. blue) can recharge in any roboport, but can only be stored in blue roboports.

The logistic network and the logistic area would be bounded to each other, different from the concept presented by ssilk.

[ofca]

Lets paint a live example:

There's an iron mine far far away, connected by railroad with main processing base.
For convenience it's connected with primary roboport network and main power grid.
We are using drones to transport iron ore somewhere in main processing base, i.e. there are provider and requester chests configured to work with iron ore.
We are using drones to transport iron ore at the remote mining site.

Currently we will observe heavy drone traffic between mining site and main base. My original suggestion was an attempt to take a stab at this problem.
ssilk's solution will work, but I still feel it's overly complicated. Let me describe exactly what I would want to happen here.

I like ssilk's wireless network analogy, so I'll go along with that.
There's only one research needed: Logistic networks. Once researched, roboport can "broadcast" one more "ssid" (network name, along with set of properties, i.e. icon, area color for minimap, etc.) in it's range. This new "ssid" is broadcast along the primary, default, global network. I think there won't be a need for more than one additional network, but if someone can provide an example of such a need, then there may be additional research that will allow roboport to broadcast more "ssids".

So, I connected remote mine's roboport with my global drone network. Drones can now fly between mine and base, construct stuff, repair stuff and transfer goods to the player.
My mine is big, I need 6 roboports to provide coverage for it's terrain. I build them and click 'join local network' in roboport's menu, which pops up a window with all logistic networks and an option to create/delete/rename them, change their background color for map, their icon, etc. Once added to correct network (i.e. "iron mine far north"), I can shift-right click the roboport and copy this setting quickly to other roboports in the mine, so they'll extend local network's area (along the global network). I'm finished with roboports. I have drones in the area, and I have my local network for goods.

Now to the chests:
We don't need new chests. We need only two new options:
1) Join local network
2) Service only local network

Both may be a checkbox. Obviously not selecting the first one disables the second one.

First option may require an assistance from list of local networks if more than one exists in the tile that the chest is located. It should automatically select one local network once checkbox is selected.
If second option is selected, then this chest won't participate in global network.

So I build my chests, assign them to mine's local network that I created with 6 roboports, and enable the isolation option (service only local network) -- both options may be shift-copy-pasted quickly to other chests. I set providers next to miners and requesters at the train station. Drones fly freely over the world map, but carry goods picked up from local providers only to local requesters -- my main base may not have one iron ingot in there, but no drone will dare to carry it there -- only train will carry the iron.

That's all. It's that simple. One new setting in roboport, two new settings in chest.

If this doesn't cover someone's use case, please describe it.


What if power goes down?
Exactly the same what happens now. Chests don't need power, and roboports won't recharge drones. Your network settings are intact, but it may be broadcast by 0 roboports.

What if I build two roboports at opposite corners of the map, light years away from each other?
- If there's a global network connection between them, goods will flow between them. That's probably an idiotic configuration, but it's YOUR configuration, so have fun
- If there's no global network connection between them, then goods will not be delivered between roboports' areas.

[SHiRKiT]

Both ideas are really close to each other, they are almost the same indeed. I think it has converged well enough and it's now up to the Gods of Factorio to help us out

[ofca]

btw. ssilk, maybe close the other threads to prevent any confusion?

[Marconos]

I agree with most here.

1) Simple named networks (new research item, 1 level)
2) no new chests, you can just assign them to a network and service levels
3) smart inserters work with logic of items in any network (like the different circuit networks)

The only change I would suggest to this is allow me to assign bots to a network.

Real world example:
I have a coal unloading station, I need X bots to service that properly and get a balance on delivery.
I have an iron unloading station, same thing as coal for balance
I have the "internal" usage area in the factory for building things and I have bots assigned to that.
Finally I would have an ammo supply network with bots assigned specifically to that. A certain number of bots where all they do is shuttle ammo to the defenses (I don't use laser turrets in my games).

In all these cases I only want to make the number of bots that I need to keep the prescribed operations running. Certain areas are more critical to make sure there are bots there to supply those locations and other can handle lag time on supplies.

Really like where the overall design is heading. We already have circuit network and essentially the named logistic networks are the same basic principal.

[ofca]

Well, I suppose the mentioned menu where you can create networks could have a settings menu, where you can set networks' icon, color, change name. There could be a setting in there that would allow you to limit number of bots servicing the network to percentage of fleet or absolute value, and set priority -- i.e. global network has priority/local network has priority

[katyal]

I prefer SSilk's idea because it allows for tons of interesting experiments. To me it is better because it does not only solve one specific problem, it adds possibilities. I also don't feel as though it is overly complicated.

Logistics networks transport two things - goods and information: given logistics area1 and area2. Chest A is in area1 and Chest B is in area2.

• 1.) area1 is connected to area2 AND chests A and B are part of the same network: goods can be moved by bots between A and B and information about the goods is available
• 2.) 1 and 2 are disconnected but chests A and B are in the same network: bots will not carry goods between A and B but the information about the chests contents is still available at both locations
• 3.) Chests A and B are in different networks: A and B are invisible no goods or info move between them

Would allow us to control mining outposts without running circuit wires from base. If you don't want bots moving from one area to the other just don't connect those areas you nolonger lose access to the information by keeping them seperate so theres no reason why you have to connect everything.

[ssilk]

@Ofca: I need to read it 2 or 3 times, but then I got it. Well, that idea is also really nice, I think that works for most cases, but I really don't have thought through all. Maybe it's the handling of only two networks or something like that. I'm not sure, my bottom says: Would work, but could not handle every side-case. In every case the devs will check the options, before they implement it, and they will take those, which is then easier to implement. We cannot know if and when.

@Marconos: I think I will make an extra suggestion for the robot handling, cause it has generally nothing to do with this suggestion.

@Kaytal: Those possibilities to handle information and items seperated and transfer over long distances are also in Ofca's suggestion.

@All: I think the real solution is anywhere here, this thread shows the devs definitely the right direction.

[katyal]

I agree that the final form this takes will probably depend on how the code is implemented, so all thats left is to keep our fingers crossed that devs decide to put this in.

[ofca]

katyal, thanks for retyping exactly what I wish was implemented, but in the future please provide scenarios that can't be accomplished with suggestion. Everything you wrote can be done with what I proposed

[ofca]

@ssilk - Like I said, there can be any number of networks limited only by physical space occupied by roboports and their range - I suggested only one additional network merely to keep things simple, and because I honestly can't think of any use for more than one non-global network in any given area; but the fact I can't think of it doesn't mean it doesn't exist

This may be expanded with additional research to prevent throwing million things at once at the player

[katyal]

@ofca: I must point out that your suggestion would not allow for a network to span across multiple areas (my second bullet point). This would mean we would still have to run ccnet from factory to outpost to control output.

Basically SSilk's suggestion would create a wireless ccnet, yours would not.

[ofca]

How so? Apparently either you don't understand my suggestion (try reading q&a at the end of my post), or I don't understand your problem

[ssilk]

Not all implications of the suggestions can be really thought completely through. In software development it's then very common to implement two prototypes to find the better solution.

[ofca]

Hey, Kovarex, give us a sticky will ya?

[SHiRKiT]

I really hope he does, but he'll probably think a lot before doing so.

[ofca]

Maybe he'll think of something we didn't

[SHiRKiT]

Maybe he'll think of something we didn't

I bet they will, if ever decide to do something like this. The downside is that even enabling this to be modded will give them a bit of work =\

[ofca]

Eh, another remote mining site and again can't use drones