Factorio Forums

TL;DR - Read the summary

Preamble

• I'd like to apologize in advance if my lexicon is a bit off - I haven't played Factorio for some time but I'd like to get into it again if I could find a mod or solution to my problem. I also understand that the Robot logic is very complicated so I completely accept that I'm a beggar here.
• Because I show screenshots of my base in this post, I know it's likely I'll receive comments to the tune of "why don't you build this way instead?". While I'm happy to accept suggestions, I'd still like to know if anyone is able and willing to make a mod that fixes the "problem" that I'm trying to identify.

Summary

I'd like to have a way to separate logistic networks that doesn't involve needing to physically separate them. Currently if you want to separate two networks, you must physically separate the roboports so that their logistic (orange) ranges do not overlap. While the game world is basically infinite, this is quite inefficient in terms of space and causes what I would consider unnecessary grief. Quite simply, I want to divorce the logistic networks themselves from their physical connections.

Clarifications

I am not referring to construction ranges in this request - I see no issues with the construction bot logic and they could remain unaltered for all I care.

Problem

I have completed my starter base and I want to move into a more grid-based, modular base construction. The below screenshot is a rough draft as to what an example grid could look like with smelters, locomotion and of course, bots!
In this particular use case of the logistic network, the robots within the cell are used for train loading and unloading and a small amount of construction bots for repair. This cell is intended to be entirely autonomous, strictly for the purposes of iron smelting. There is a small amount of circuit logic that tells the cell whether to produce based on activity inside the cell. This circuit logic for this cell would break if the logistic network inside this cell was connected to the "mainline" logistic network.

The cell described in the previous paragraph is supported by the roboports inside the circle labelled '2'. The roboports within circle '1' are what I refer to as the mainline logistic network. The region identified within the third circle is a kind of no-man's land. This is the area where some construction space overlaps but there is a clear gap of logistic networks as shown below.
It would make a lot more sense to be able to place the roboports within the cell closer to the actual railway as opposed to swinging the railway into the middle of the cell as I am currently doing, but I currently have to sacrifice one base objective for the other, and I'm not a fan of compromise.

Solutions?

Okay, so how can we mod away this problem? I'm not a modder, I've only taken a couple computer science classes, so don't look at me for technical answers! But I have a vision. Here's my proposal and sort of a mock workflow for what it could look like.

1. When roboports are placed or removed on the map, they affect their "physical" logistic network like the base game. When the roboports are not "linked" to expand the logistic network, they are discontiguous and completely unaware of eachother. This is an array of physical logistic networks where the members are the roboports.
2. In addition to tracking the physical logistic networks, the game/mod tracks an array of "virtual" logistic networks. Similar to the physical logistic networks, the roboports are members of their definied virtual network. Additionally, bots, chests, and chest contents are members of the virtual network, NOT the physical network as in the base game. Roboports are members of both physical and virtual networks.
3. When a roboport is placed (without a blue print) it is automatically a member of a default virtual network. Call it whatever you want, undefined, null, network 0, native, etc. I'm going to use network 0. Roboports still follow the same logic as the base game to determine which physical network they belong to (I'm assuming based on whether they are neighboring with another roboport or are orphaned on their own).
4. The roboport will have a GUI extension attached to it to define the virtual network of which it is a member. Think of the same GUI method used for train stations - the player can free-type the new network's name or select from a pre-existing network name.
5. Once a roboport has had its virtual network defined, this property of the roboport can be transferred into blueprints, copy/pastes, or Shift+Left Clicks and Shift+Right Clicks similar to train stops.
6. When a bot (construction or logistic) is created on the world surface by the player, it is automatically a member of network 0. There would have to be a new property for each bot that tracks which virtual network it is a member of. The bot will float in place if there are no roboports that are members of network 0, or travel to the nearest roboport of network 0 as one would normally expect. For a bot to be adopted to a specific virtual network, they must be placed into a roboport that is also a member of that virtual network. When the bot is adopted into the virtual network, it has the property updated in its instance in the game to identify it as a child of that virtual network. I have no idea how well this is going to work with stacks/inventories of robots in the game, perhaps this can be dynamically handled when the bots are dispatched for work/jobs/tasks? There could also be a mod option for the player to set which virtual network these "surface" bots are members of when the player manually places them.
7. Logistic chests must be given a similar level of respect as bots when it comes to their virtual network membership. I believe a single select dropdown GUI extension to the chests is the simplest method. To continue the analogy from point four, this would make chests like locomotives as roboports are like train stops.
8. I won't sit here and claim to know how the work/job/task scheduling of robots works or try to give an idea as to how this would work on a logic/algorithmic level. But obviously, the goal is that logistic requests occur only within their own virtual networks. Supply still goes to demand and the priorities of bots don't change, but they are limited to their virtual networks. But there are always exceptions. I cannot envision a way to limit construction bot jobs, so I believe those would have to remain as they are (whichever is closest and able across all networks). The player's own logistic requests and trash pickup would also have to be serviced by all virtual networks. I suppose it's not impossible to whitelist or blacklist virtual networks on these functions, but I'm forgetting that I'm the beggar here. If this feature were to be implemented, the variable would have to be consistent across all roboports in the virtual network. In the case of player logistic requests, it should not matter which roboport the player is in range of, so long as a virtual network that can support the request can traverse the journey to the player.
9. Logistic and construction bots that belong to a virtual network will not be given tasks outside of the range of the roboports within their virtual network (possible exceptions for player logistics). This is to prevent sprawl of the bots between physical locations. The bots assigned to a virtual network should stay in that exact area. However, the bots should be able to travel outside of their immediate neighborhood. It is entirely possible to have a virtual network be discontiguous but the physical network be contiguous. As long as the two virtual networks are able to "communicate" over the physical links between roboports, tasks should be able to be received within the same virtual network.
10. Because of the previous statement, bots should be allowed to charge at whichever roboport they require as normal.
11. If all roboports belonging to a virtual network are dismantled while bots belonging to that same network are working on tasks, those bots will freeze in place on the surface as would occur in the vanilla game until they are either picked up or a roboport belonging to the same virtual network is placed down.

Considerations

Some other thoughts and questions about such a mod that don't necessarily pertain to the workflow above are listed below.

• How would uninstalling the mod affect save games? How badly is that going to break things? In theory everything just becomes a mega-network as the base game doesn't use the new properties, but I'm no expert.
• How would this work in multiplayer? How do individual player logistics get dealt with?
• I don't have any reason to suspect that this mod would impact personal construction robots but perhaps there's a devil in the details. Similarly, I have left out repair packs from all of this. There's a possibility they need to be given some kind of special care but I haven't given them much consideration.
• Minor QoL changes, mainly GUI. Things like hovering over a chest - how do we show the player which roboport(s) the chest is associated to? In the base game it is simply all roboports in range, but this would change under a mod like this. Also, if construction items are missing bots, from which network? If blueprints are missing items for construction, from which network?

Conclusion

I wrote far more on this than I had initially intended. If you made it to the end, good for you! I hope this gives someone with the skills and desire the inspiration to make something really great. One last thing to mention before I sign off is that I had the original imagination that the setting of the virtual network on chests and roboports could be accomplished using the circuit network and virtual signals but I think that's a bit much to expect from the first post.

Signing off!

I poked around raw.txt and the api page. Very, VERY interestingly the logistic_network an entity is a part of is a read-write value! https://lua-api.factorio.com/latest/Lua ... ic_network

A mod may be able to directly edit the network the roboport is a part of. Only works for logistics, not construction bots.

Would be easy to test: a console command could just change the network of nearby roboports. Easiest way to ram through and see what can happen.

Possible issues:
Does the logistic robots immediately get attributed to the different network?

Does the game handle a chest being in range of two networks? (normally different logistic networks never overlap, though you could make a roboport with a different range than normal... [it probably works like a power pole]). Equipment doesn't have a logistics anything value, so that's probably behind some other logic. Not surprising, you normally don't supply/store/etc stuff on the network. (that'd be a neat mod wouldn't it?)

Does the game immediately give you the middle finger and turn the roboport back?

I was thinking the most sensible way (to me) to implement this behavior internally would be to re-use signal code. Run specific invisible wires or "transmitters"/"receivers" that provide nearby roboports with what network they should be on. The latter could actually be done mod side if changing networks does work: change a gui and it could get a roboport in range, find all connected roboports, and switch what network they're on. Nobody may have messed with this before, so the game could do all sorts of broken things: if I go from three networks down to two by manually, would it detect the third network is disconnected and discard it, or does removing the network only happen if all roboports are disconnected traditionally? Hopefully not, cause that would imply a ton of other bugs would be present (the roboport would exist in two networks, but itself would only exist in one...)

Edit: only option is to make a bunch of roboports with smaller ranges. I think I've seen some with no support for bots leaving/entering, only charging, don't know if they had logistic ranges.

Moddability of robot behavior is non-existant. Moddability of logistic networks is extremely limited. Also the engine does not support overlapping networks.

Conclusion: As long as you just want a bunch of polygon-shaped networks that never overlap and never touch each other you can mod it with invisible roboports (sometimes called "range extenders" in other mods).

Thanks to the both of you for your constructive responses! It's good to see some interest in this idea - makes me feel like I'm not alone.

Honktown wrote: ↑Mon Dec 23, 2019 11:44 am Edit: only option is to make a bunch of roboports with smaller ranges. I think I've seen some with no support for bots leaving/entering, only charging, don't know if they had logistic ranges.

I think this would be a step in the right direction if the ideal implementation is not possible. Do you know if the size of the ranges could be dynamically edited in game and copy/pasted with the copy entity settings and blueprint functions?

eradicator wrote: ↑Mon Dec 23, 2019 1:39 pm Moddability of robot behavior is non-existant. Moddability of logistic networks is extremely limited. Also the engine does not support overlapping networks.

Conclusion: As long as you just want a bunch of polygon-shaped networks that never overlap and never touch each other you can mod it with invisible roboports (sometimes called "range extenders" in other mods).

Do you know if any such mods exist? I looked up a couple mods in the portal (haven't actually installed/tried them yet) but I can't seem to find a mod that matches the function I'm looking for. Robot World seems the closest but it does a lot more than just range modification.

Thanks!

Closest I see is:

https://mods.factorio.com/mod/Robo-Char ... 000ce98539

The mod page says MIT, and that's the closest license I can find.

Ironically, the size of those is already 2x2, so you could literally grab that mod and see if 2x2 roboport ranges are sufficient. It would need at least one normal-sized roboport in range though.

If that's not good, it'd be easy enough to write a loop so it makes a bunch of differently ranged entities, and adds the range onto the end of the name. Maybe a few more lines so other parts of the code (technology unlock if any, order in inventory, etc) are proper. Do the same thing for base roboports, so maybe there's a 1/2 range version and a full range version.

Edit: whoops. That mod even includes differently ranged versions: "Mod that adds a new small charging towers (one tile) that can charge 4 robots, though they can't dock with it, and they have 1/2, 1/4, and 1/8 the supply area of vanilla roboport."

Honktown wrote: ↑Mon Dec 23, 2019 5:19 pm Closest I see is:

https://mods.factorio.com/mod/Robo-Char ... 000ce98539
...
Edit: whoops. That mod even includes differently ranged versions: "Mod that adds a new small charging towers (one tile) that can charge 4 robots, though they can't dock with it, and they have 1/2, 1/4, and 1/8 the supply area of vanilla roboport."

Thank you!! I installed and played with this mod in a sandbox and while it's no virtual logistic network, it certainly solves my problem. I guess this forum post can remain alive if someone wants the challenge but from the responses so far it seems like that's not possible due to API limitations.