Add Enable/Disable switch to roboports

[hitzu]

TL;DR

Add a circuit control to turn roboports on or off instantly, so players can control logistic networks.

What?

Add a circuit-controlled switch to roboports, allowing players to instantly turn them on or off without waiting for the internal roboport battery to drain. This would make it easy to split or isolate parts of a logistics network when needed. For example, on Fulgora, players could turn off roboports during nighttime lightning storms to stop robots from flying into dangerous areas.

Screenshot_1883.png (228.27 KiB) Viewed 1678 times

Crescent-shaped island, needs one network during the day that better be split into two during the storm

dqwfqwfQWq.jpg (260.07 KiB) Viewed 1678 times

Standard Enable/Disable toggle GUI for roboport

Why?

I have a crescent-shaped island on Fulgora, and my robots fly across an ocean area where they get damaged during storms. By splitting my logistics network at night, I could keep robots safe from electric storms, avoid resource loss, and manage logistics better. This would improve Factorio by letting players protect their robots and control their networks more effectively in tough environments.

[AileTheAlien]

This seems reasonable to me. Almost everything except smelters can be hooked up to circuit wires, and most things can be enabled or disabled. Like, even offshore pumps can be enabled or disabled by circuit. I think the only other things that can't be controlled by circuit are splitters and underground belts, but those would lose resources inside the animation or underground, if they could be shut off arbitrarily.

[Tinyboss]

I think the only other things that can't be controlled by circuit are splitters and underground belts

Thrusters and recyclers off the top of my head.

[hitzu]

I think the only other things that can't be controlled by circuit are splitters and underground belts

Thrusters and recyclers off the top of my head.

Radars, furnaces, reactors, steam engines, heating towers, heat exchangers, lightning rods/collectors, solar panels, and accumulators—many don't make sense to control directly or at all. But lacking control over roboports is the oversight to my mind, especially because it's impossible to make a working alternative design

[Funtime60]

You can get part of the way there by putting the roboport behind a power switch.

[Rseding91]

While this sounds interesting as a gameplay element it has a few issues:

* You have zero control over where robots go when a roboport turns off. If it splits a network some robots will go to some side and some to the other. If it’s the last roboport in that network, all in-air robots will find the nearest powered network and permanently move to that network.

* Splitting and meeting a logistic network is an extremely expensive operation and will cause lag spikes as network sizes grow.

I don’t see this as something that will realistically make for good gameplay. Its trying to solve something that already has solutions (lightning rods to protect the robots as they fly). Before you’re able to build the lightning rods there are other solutions such as belts and trains.

[Shirasik]

Would be a better solution to force bots to follow roboports during travel? Like if there is a port nearby then that area is considered safe and being allowed for bots to fly over. In other words to disallow bots to make shortcuts through areas without logistic/construction coverage.

[Rseding91]

Would be a better solution to force bots to follow roboports during travel? Like if there is a port nearby then that area is considered safe and being allowed for bots to fly over. In other words to disallow bots to make shortcuts through areas without logistic/construction coverage.

That is also not going to happen for performance reasons. Robots don’t do any path finding - they move directly towards their target.

[Sad_Brother]

If someone would make Rail support to act like lightning attractor (harmlessly protect nearby territory) problem would be solved.
But I would prefer to split logistic network where I cannot protect it.

[Shirasik]

Would be a better solution to force bots to follow roboports during travel? Like if there is a port nearby then that area is considered safe and being allowed for bots to fly over. In other words to disallow bots to make shortcuts through areas without logistic/construction coverage.

That is also not going to happen for performance reasons. Robots don’t do any path finding - they move directly towards their target.

Anyway you need to rework guidelines for bots.
Attached .png: scheme and legend.
Attached .zip files: editor extensions' testing scenarios. Mods required: flib, editor extensions.
Testing concept: bots has to deliver items over roboportless area. Item source: infinity passive provider chest. Item destination: infinity requester chest. Roboport at item source have 350 common logistic bots loaded. Naive expected drone route: straight line from item source to item destination. How to use: load scenario, unpause, switch to satellite view, make sure "worker robots" filter is on.

drone deliver.zip: bots move directly until they decided to recharge. Then they heading to roboport that is approximately at the same distance as destination but one that located at the right side. After recharge they move directly to destination up until they decide to recharge what they deciding to do at right side again this time they moving horizontally to the right. Bots' route takes form of zigzag. So in essence they following roboport coverage but doing that very weirdly.

drone deliver 2.zip: I moved "right side" much further away. In this setup bots move directly to destination not following roboport coverage.

Is bots "following" logistic coverage is a bug? Shall I report that in an appropriate manner?

[Rseding91]

Is bots "following" logistic coverage is a bug? Shall I report that in an appropriate manner?

See https://factorio.com/blog/post/fff-374 specifically the "Mitigation for robot pathing over lakes" section.

[Shirasik]

See https://factorio.com/blog/post/fff-374 specifically the "Mitigation for robot pathing over lakes" section.

So in essence bots following coverage but deviate from it for up to (1-x)*flyingReach where x is bot's battery charge threshold at which bot deciding to recharge. What if you will add some way to manage charge threshold? Low enough threshold will guarantee bots never go far away from coverage without any pathfinding needed so bots will avoid dangerous areas (which is whole undeveloped Fulgora areas during nighttime). Following OP's needs, management must be available through circuit network so will be possible to implement circuit network managing bots to move as usual during day and to stick to roboports during night.