Factorio Forums

Thought about this a lot more and I think it would make the most sense to have a logistics gateway be its own entity. Updating my original post.

A gateway would be a new entity for the purpose of creating gateway links to neighboring roboports.

The gateway would have a linking radius of the same size as a logistics radius, and will not provide a construction radius.

Bots can charge at a logistics gateway.

Logistics gateways can not support any bots, so bots will dock at the nearest linked logi network.

Gateways, when placed, will link up with roboports and other gateways with an alternate colored dotted line.

Extending your logistics network with several chained gateways will make bots follow a defined path to the remote roboport.

As before, bots destined for remote networks must arrive at the roboport connecting to the gateway, then arrive at the gateway, then arrive at the remote connecting roboport, then fly freely to their destination or to the next connecting roboport in the chain. Bot count totals from linked networks.

Gateway radiuses are used only for linking and will not provide its own logistics or construction area.

Touching logistics radiuses will create normal links just as before, gateway radiuses touching other gateway radiuses or logistics radiuses will create gateway links.

Any gateway that only links to one logi network will not function, regardless of how many links to the same network.

Logi chests within only a link radius will not function.

Should logi chests supply remote networks? Whether they do or don't I think a new global or local type chest should be available for research.

Regardless, the lack of path control is the biggest problem to logistics network. Having to split up networks to prevent bot genocide results in isolated networks and limits the usability of larger, more complicated networks.

Original Post

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

The ability to change an existing logistics network path into a gateway, which is similar to rail signals, splitting a logistics network up.

Bots travelling from one network to another then must go through the gateway link as a way to route traffic.

Perhaps add an "Edge" checkbox on the roboport, when two linked roboports are both checked for Edge then they become a gateway and the link color changes.

Bots destined for a remote network must arrive at it's current networks edge which routes to the remote network, and then arrive at the next edge in the chain and so on.

Please describe this network separation more thoroughly.

I have seven roboports arranged at the points and center of a hexagon. All roboports on the outside are connected to the center and also to both neighbors. I want to split this into four networks: top two, lower-left two, lower-right two, and center one. When I've done this, the center roboport connects to all three other networks, and the other six roboports each connect to one roboport in their network and one roboport in a different network. How should I configure my roboports to achieve this?

In this scenario, the hexagon wouldn't be able to automatically configure itself in the manner you describe. A simple system to remove other link paths between gateways would result in isolated in-range roboports.

I think you would have to be able to choose the link type in the GUI. Perhaps via shift click on a roboport to remove all links and 2 buttons on the roboport "Create Link" and "Create Gateway" allowing you to draw paths between in-range roboports.

Normally, this would be a quick task. You create a gateway, between roboports with no other normal links to each other. But in the case of the hexagon, the links would need to be removed first.

Once set up, the network would look like the image below. Blue paths are gateway links and orange paths and regular links. Bots currently within network 1-2 would have to arrive at roboport 2, and then roboport 3 before moving to objectives within network 3-4. But they can still fly directly to their objective if it is within the roboports radius, whether or not it overlaps with another network.

Thought about this a lot more and I think it would make the most sense to have a logistics gateway be its own entity. Updating my original post.

A gateway would be a new entity for the purpose of creating gateway links to neighboring roboports.

The gateway would have a linking radius of the same size as a logistics radius, and will not provide a construction radius.

Bots can charge at a logistics gateway.

Logistics gateways can not support any bots, so bots will dock at the nearest linked logi network.

Gateways, when placed, will link up with roboports and other gateways with an alternate colored dotted line.

Extending your logistics network with several chained gateways will make bots follow a defined path to the remote roboport.

As before, bots destined for remote networks must arrive at the roboport connecting to the gateway, then arrive at the gateway, then arrive at the remote connecting roboport, then fly freely to their destination or to the next connecting roboport in the chain. Bot count totals from linked networks.

Gateway radiuses are used only for linking and will not provide its own logistics or construction area.

Touching logistics radiuses will create normal links just as before, gateway radiuses touching other gateway radiuses or logistics radiuses will create gateway links.

Any gateway that only links to one logi network will not function, regardless of how many links to the same network.

Logi chests within only a link radius will not function.

Should logi chests supply remote networks? Whether they do or don't I think a new global or local type chest should be available for research.

Regardless, the lack of path control is the biggest problem to logistics network. Having to split up networks to prevent bot genocide results in isolated networks and limits the usability of larger, more complicated networks.

i want this!