Construction Robots switch networks when target roboport is out of power

[Raxoraptor]

I ran into this problem while using an isolated logistics network for city blocks. When constructing a new city block, sometimes roboports will be constructed before their connecting power poles, and thus will run out of charge once a few robots recharge there. When this happens, I was under the impression that bots that were pathing to the roboport that is now out of power were supposed to re-path to the nearest roboport within their current network. However, I have found that my construction robots have been able to path to roboports within the isolated networks of my city blocks.

The problem is reproducible with the blueprint in the linked doc. Just construct The city block, put logistics and construction robots in the network, and order construction robots to construct a new city block adjacent to the current one. You should see that construction robots make their way into the new city block's isolated network.

https://docs.google.com/document/d/1Q-w ... sp=sharing

[SoShootMe]

I was under the impression that bots that were pathing to the roboport that is now out of power were supposed to re-path to the nearest roboport within their current network. However, I have found that my construction robots have been able to path to roboports within the isolated networks of my city blocks.

Bots do not fly/migrate from one network to another, unless their home network is destroyed in some way, for example when all roboports are removed or out of power.

It seems to me that what you are seeing is the expected behaviour, only if there are no other roboports.

[Raxoraptor]

It seems to me that what you are seeing is the expected behaviour, only if there are no other roboports.

There are still other charged roboports in the correct network. It is only the newly constructed roboports that run out of power, as sometimes the port is built before its respective power pole

[Loewchen]

There are still other charged roboports in the correct network. It is only the newly constructed roboports that run out of power, as sometimes the port is built before its respective power pole

Cannot produce, bots will not switch to a different network if the original network still exists. If you can show bots changing networks instead of moving to a still powered port in the same network post a simple save file and exact steps to produce the issue, see 3638.

[Raxoraptor]

So, I have found the issue is that if a roboport is built before the power pole and then another roboport is built adjacent to it, when the first roboport runs out of power, the second one will be disconnected from the rest of the network and will be considered its own network. Once that roboport runs out of power, bots pathing to that port will merely path to the closest roboport, even if it is not part of its original network. The solution I see to this, is that if a bot is pathing to a roboport that has been disconnected from its network via a connecting roboport running out of charge, the bot should store its items and return to the nearest roboport within its network.

The problem is reproducible with the blueprint in the previously linked doc, and with the save file attached. Just copy the city block, ensure there are construction and logistic bots in the network, and order construction robots to construct a new city block adjacent to the current one. You should see that construction robots make their way into the new city block's isolated network.

[SoShootMe]

So, I have found the issue is that if a roboport is built before the power pole and then another roboport is built adjacent to it, when the first roboport runs out of power, the second one will be disconnected from the rest of the network and will be considered its own network. Once that roboport runs out of power, bots pathing to that port will merely path to the closest roboport, even if it is not part of its original network.

In the general case: a roboport running out of power may cause a network split, resulting in one or more new networks being created and one or more roboports being assigned to the new network(s).

My guess is that when a roboport's network is changed, robots heading for it are also changed to that network but are otherwise unaffected. This would trigger the next part of the behaviour you describe, because when the second roboport runs out of power, the network is destroyed and robots pathing to it must find a new network, which may or may not be the original network from before the split.

[Raxoraptor]

In the general case: a roboport running out of power may cause a network split, resulting in one or more new networks being created and one or more roboports being assigned to the new network(s).

My guess is that when a roboport's network is changed, robots heading for it are also changed to that network but are otherwise unaffected. This would trigger the next part of the behaviour you describe, because when the second roboport runs out of power, the network is destroyed and robots pathing to it must find a new network, which may or may not be the original network from before the split.

That’s my thought process. I feel this should not be the intended behaviour though. When a roboport has just been separated from its network, it is much more predictable and reliable behaviour for robots pathing or said robot port to return back to their own network.

I see this as a problem because it can be triggered merely by constructing an addition of a network adjacent to another network. The way construction robots work, there is no workaround to this spontaneous switch in networks.

[FuryoftheStars]

That’s my thought process. I feel this should not be the intended behaviour though. When a roboport has just been separated from its network, it is much more predictable and reliable behaviour for robots pathing or said robot port to return back to their own network.

I see this as a problem because it can be triggered merely by constructing an addition of a network adjacent to another network. The way construction robots work, there is no workaround to this spontaneous switch in networks.

The issue I see here is that now you not only need robots to remember their current network, but their previous, too. This creates some issues.

How many past networks should robots remember? What's the expected behavior if first the network gets split majority in one and 3 in another, then the 3 network gets split 1 and 1? If robots only remember 1 history, then they're going to go over to the other network of 1 roboport first, and then if that one goes down, they'll revert to the current undesirable behavior. So should they remember 2? 3?

How long should they remember this history? Do you just want this behavior if it happens within 5 minutes? An hour? Or indefinitely? Would it be desirable for them to switch back to their old network if the new one is never reconnected (say from you deconstructing the power failed roboport that caused the split: you changed your mind or something about having one there) and then something happens to their current one say 10 hours from now when you probably no longer care (or remember!) which network was their "original".

Is it necessarily always going to be the desirable behavior? And what happens if the original network goes completely down and then comes back? My guess is that it doesn't get assigned its original id. Which also makes me wonder... if trains get assigned new ids every time you add or remove a single wagon at the end, what about logistic networks when you add or remove a roboport?

Ultimately, though, this isn't a bug but more of a feature request.

[SoShootMe]

When a roboport has just been separated from its network, it is much more predictable and reliable behaviour for robots pathing or said robot port to return back to their own network.

Say you have two roboports, far enough apart to create two networks but close enough that you can place a third to join the two networks. If you place then remove that third roboport, which of the original two roboports was separated from its network?

The obvious answer extending the above to the general case of multiple roboports is "the smaller network" (eg fewer roboports), but what if they are of equal size? Even if they aren't, and therefore the result of robots returning "back to their own network" is predictable, there are certainly cases where I would consider it undesirable (the simplest being accidentally joining two networks).

I think there is no perfect solution. The current behaviour may be the best compromise.

[Loewchen]

For further discussion make a feature request or open a Gameplay help topic.