Constructions robots get "lost" in unpowered roboports

[JasonCurnow]

Short bug: Construction robots will park in unpowered roboports and get "lost" until the roboport gets power.

I'm building a large megabase (15K SPM) and I'm running into a problem with construction robots. I am building some massive projects (i.e. steel for purple science) and lay down my blueprints, my rail stop and support for my main construction train. I add ~600 construction robots to let it build itself.

When I return, I find that the logistic network is only left with 50 construction bots. It turns out that the bots have built out roboports before they build out power to the roboport, then landed in that unpowered roboport. The bot is then "lost" and unavailable for construction. The bots re-activate when power is added to the roboport.

Most of the time the remaining construction 'bots will power up the roboport, but it can take hours and hours to build something that should really only take about 30 minutes.

Can you fix Construction Robots so they don't land in unpowered roboports?

[NotRexButCaesar]

If you make a separate “construction grid” blueprint that contains power and roboports, construction should be much more quick.

[JasonCurnow]

That's a good idea - Whitelist only roboports and power in one blueprint and then a 2nd blueprint with everything. I might try that for my next big build!

Regardless, I still don't think robots should stop in unpowered roboports and get lost.

[eradicator]

Regardless, I still don't think robots should stop in unpowered roboports and get lost.

Are you sure they do? When freshly built the ports do get some "free" initial charge which i suspect might be the real culprit here. You can try this little snippet to disable the initial charge:

Code: Select all

/c script.on_event(defines.events.on_robot_built_entity, function(e)
  e.created_entity.energy = 0
  end, {{filter='type', type='roboport'}})

[ssilk]

I would change it so: robots should try to avoid parking in roboports, that have currently not enough power supply.

[jodokus31]

Maybe roboports could stay part of the network, even if unpowered?

There is also this case, when you have an outpost with a roboport for automatic building and repair, and somehow the power gets cut while constructing. After a rather short while the robots flee to the next powered roboport, which can be miles away

[cbhj1]

Perhaps relevant from a different angle, Why do roboports start with power?

[Kyralessa]

Perhaps relevant from a different angle, Why do roboports start with power?

If I recall correctly, it's just a convenience factor when you're laying out a bunch of them.

An unpowered roboport doesn't show a connection to powered roboports.

When you're trying to lay them out so they connect, this allows you to put several on the map with connections without having to wait a while for each one to charge first to show the connections.

[cbhj1]

If I recall correctly, it's just a convenience factor when you're laying out a bunch of them.

An unpowered roboport doesn't show a connection to powered roboports.

When you're trying to lay them out so they connect, this allows you to put several on the map with connections without having to wait a while for each one to charge first to show the connections.

If that is the case, shouldn't it instead behave more like the electrical network elements, where the range and connections show regardless of power?
if the range and connections were shown regardless of power, the roboports could start without charge, preventing orphaned bots/networks.

[JasonCurnow]

I would change it so: robots should try to avoid parking in roboports, that have currently not enough power supply.

That's a better way to put it, yes. Thanks!

[eradicator]

I would change it so: robots should try to avoid parking in roboports, that have currently not enough power supply.

It's easy to say "enough" but how do you even define that? (Let alone making it not kill performance.)

@JasonCurnow:

Did you test if the initial charge is actually what's causing the issue?

[torne]

Perhaps relevant from a different angle, Why do roboports start with power?

Starting with power means that they contribute to the construction area right away, which might be necessary for the power poles intended to bring them power to be in construction range. The construction range of roboports is set up to be just enough to build another roboport next to it (optionally with a small gap in case you don't want them to join their logistics ranges together), and that might *not* be enough to build the required power poles, depending on the arrangement of the poles.

It's not just that the range/connection don't *show* when the roboport is unpowered; the range/connection stops existing when the roboport has no power. Otherwise, you could blanket a large area with roboports, not bother to power most of them, and still be able to count it all as part of your logistics/construction area.

I would hope (but haven't tested) that robots would never actually dock in a roboport that was unpowered at the time of docking; it would be very rare anyway because robots want to charge before docking unless their battery is *very* close to full already, and they can't charge from an unpowered roboport. As other folks have said I suspect what's happening here is that they're docking while the initial "free" power hasn't run out yet, and then the power runs out afterward. If that's the issue then that could, I guess, be prevented by requiring that the roboport have more than the initial free power amount to be considered as a valid charge/dock location: that would enable it to sit there providing grid coverage until the passive drain of the roboport itself depleted the energy, which hopefully is long enough to allow power to be built out to it.

That might be too specific an edge case though; even with that restriction you could, with some plausible blueprint layouts, still run out of power and lose construction grid coverage in such a way that the power poles will never be built without manual intervention. It wouldn't lose any *bots* any more, but it still doesn't make it always okay to just slap down a complex blueprint all at once; it's still beneficial to place power/robot infrastructure before the rest.

[cbhj1]

Starting with power means that they contribute to the construction area right away, which might be necessary for the power poles intended to bring them power to be in construction range. The construction range of roboports is set up to be just enough to build another roboport next to it (optionally with a small gap in case you don't want them to join their logistics ranges together), and that might *not* be enough to build the required power poles, depending on the arrangement of the poles.

This sounds like a BP design mistake, relying on inherently unstable construction zone to power itself, especially when the bots that are building in the area will sap what little power it starts with.

[torne]

If you're building roboports at the maximum connected logistic zone distance from each other the construction zone of the existing roboport extends 3 tiles past the new roboport; that's enough to construct any regular electric pole but if you were using substations for power (like in many solar+roboport arrays) it might not be in range in some orientations of the blueprint.

It's more likely in cases where you're intentionally leaving a gap between logistics networks, but that's much less common.

[JasonCurnow]

If you make a separate “construction grid” blueprint that contains power and roboports, construction should be much more quick.

I tried to first construct the power and the bots this morning on a very large iron smelter build (~800 fully beaconed smelters) and it helped, but didn't really fix the problem. I laid down my blueprints, built some core roboports and fed it all the power poles it needed and enough roboports. Unfortunately, the construction bot logic built a lot of robports in places that the power grid hadn't been laid down and they didn't have power. The 'bots, of course, landed in these unpowered roboports.

(FYI, I use a long construction train that delivers all of the parts needed to build something like this - Lay down the blueprints, set up the train stop and watch it go. All the parts are built at "the mall" that creates a big stock of all the parts I use for building)

[JasonCurnow]

If you're building roboports at the maximum connected logistic zone distance from each other the construction zone of the existing roboport extends 3 tiles past the new roboport; that's enough to construct any regular electric pole but if you were using substations for power (like in many solar+roboport arrays) it might not be in range in some orientations of the blueprint.

It's more likely in cases where you're intentionally leaving a gap between logistics networks, but that's much less common.

Nope, no gap. It's just that roboports get built out by the robots before power for that roboport does and the 'bots land in the unpowered roboport. This is very common on build builds - i.e. I'm laying down 800+ furnaces to smelt iron. The total area is ~400X500 tiles, so that's a lot of area to cover.

You can see what's happening below - This is after I manually laid down power poles to the. Blue is power, and the tan dots are roboports - You can see that the 'ports are built out pretty randomly. In this particular build, most of the issue is past and most roboports are powered, but you can see that there are still a lot of roboports built out without connected power.

[torne]

Nope, no gap. It's just that roboports get built out by the robots before power for that roboport does and the 'bots land in the unpowered roboport. This is very common on build builds - i.e. I'm laying down 800+ furnaces to smelt iron. The total area is ~400X500 tiles, so that's a lot of area to cover.

Sorry, I was responding to cbhj1 saying that correctly designed blueprints shouldn't require the newly constructed roboports to be contributing to the construction zone for the power to be built, but didn't include a quote.

My earlier post was about the issue you're having; I don't think there is a straightforward solution to it. Just preventing robots from ending up in unpowered roboports doesn't seem to me to be enough to guarantee this kind of construction will succeed, or even to guarantee you don't end up with robots split across partitioned (but powered) networks, because even if no robot ever enters a roboport that isn't already properly connected to the power grid, the roboports that are *not* yet properly connected still have a passive drain that will eventually cause their buffer of free power to run out, which can leave you with ghosts that are out of reach of all of the powered roboports.

The only way I can think of to actually prevent large slow builds getting stuck sometimes without changing how robots choose the order of jobs (which has been suggested in many previous threads already but rejected for performance reasons) would be to also remove the requirement that a roboport have power to be part of the network, but that would allow you to just intentionally build unpowered roboports in places where you don't need the robot charging capacity, which seems undesirable.

When I've done very large bot construction it's usually been using the Recursive Blueprints mod to have it automatically happen in incremental chunks for efficiency, but that's rather more complex

[cbhj1]

Imagine if the roboports started without power.

large blueprints would naturally increment as the infrastructure progresses (power and ports)
bots would no longer be able to place a port, then immediately discharge it to sleep, nor would they be able to make a chain of unsupported ports

that was why I asked why they start with power, if it is just to show what networks would connect, that's UI territory rather than what we have now.

[torne]

Imagine if the roboports started without power.

That was my point though: there are designs that would become fiddly, orientation sensitive, or unbuildable if newly built roboports didn't extend the network.

[cbhj1]

could argue that things are a bit fiddly already, example: viewtopic.php?f=6&t=96412