Factorio Forums

I've been curious about robot pathing for a few years now from a technical standpoint... This isn't really a suggestion, because it's more for my learning lol.

From playing, the logic seems to roughly be like this:
1) Requests are created by the player (logistic or construction) at position (x1, y1)
2) Bots are "Activated" and are instructed to fly to position - only stopping to refuel
3) They have task assigned like "grab item on floor and goto (x2,y2) and drop item in entity chest_01"

The only real downside to this approach from a gameplay perspective is the infamous concave roboport layout.

My understanding from other threads I've seen is that full pathing per robot would be computationally expensive, which totally makes sense.

But is there any *technical* reason why roboports couldn't make a "linked-list" type of pathing?
I was thinking something along the lines of:
1) use the closest roboport (R1) to try to fulfill the request activating bots
2) If that's not enough, expand to next linked roboport(R2) and try to fulfill the request, etc.
3) each bot would be activated with a "requestId" and instead of instructing "goto (x1,y1)" to pickup entity it would be instructed to goto next roboport in the chain.
4) When a bot arrives at the next roboport, it's instructed the next roboport to fly to.
5) Once it arrives at the original roboport (R1), then it gets the proper instruction as it does today, to pickup item. If the destination isn't within R1 range, use the same method where the roboport does a single pathing calculation to figure out the destination of the object (via roboport links).

This could obviously be optimized a ton too, but whether it's 1 bot or 1,000 the "path" calculation is the same for 98% of the flight, until they reach the original roboport, where they then need to path to the location. Or am I missing something?

I'm no expert, but what you are describing sound like a graph traversal to me, locating the nearest roboport and expanding to the one next to it is similar to a pathfinding in terms of computation. That's the expensive step. ( the number 2) Doing it "per robot" or "per request" doesn't seem like it changes much the amount of computation that would eventually be necessary.

Players can make logistic networks very large and complex with thousands of them, then it's multiplied by the number of robots. I think it would be prohibitively costly to try and update the schedule of robots several time per delivery in addition to their recharge already, because that would "force recomputation" of the structure of the network, currently robots are mostly unaware of it, that causes the infamous concave thing, they seek a position that they know belong the same network, with no regard to what is in between them and the target in straight line, they only consider a little the robotport proximity relation when they need to recharge.

In other word from what i understand from your proposition and from the game current state, ( both could be wrong ) , there wouldn't be much difference in the cost of a "full pathing" per robot and what you describe, because they both imply potentially sorting the full linked list or tree of roboport proximity relation a higher number of time than curently.

Reading your post and then re-considering, I think my solution would work for getting the bots to the request. But once they arrive and need to decide where to go next is where it would start adding up... If a request needed to go to 15 different locations on the map, it would need to do the graph traversal 15 times. I don't think one traversal is that expensive btw (I can run a 20x slowdown in JS and do graph traversal in <1s). But now add/multiply that by all the other requests players might have all at the same time.

That being said, I think you could probably create a cache of all the "from" nodes and "to" nodes. Maybe do some rollups/summarizing based on chunks. And this could be multithreaded - have the bots go to the nearest roboport after picking something up and wait for instruction. But at that point it's becoming much more complex code than just "go straight" for not much gain...

saors wrote: Mon Sep 29, 2025 3:30 am Reading your post and then re-considering, I think my solution would work for getting the bots to the request. But once they arrive and need to decide where to go next is where it would start adding up... If a request needed to go to 15 different locations on the map, it would need to do the graph traversal 15 times. I don't think one traversal is that expensive btw (I can run a 20x slowdown in JS and do graph traversal in <1s). But now add/multiply that by all the other requests players might have all at the same time.

One graph traversal can be ok, but some players have massive array of solar pannels that can have funny pattern to minimize the number of roboports, or many robotports for redundancy , it can quickly add up, that's one end, and the other end is the number of request and their frequency, both are counpounding, that was my main point, but there are also other things, like sometimes the concave "problem" actually helps the player, when you have a little coverage gap in your base, the robots don't go "around". Than can happen at larger scale if you have 2 square network next to each other, and you create a bridge, the robots can will attempt to cross "everywhere", they won't make the detour to use the bridge, this is often time a desirable behavior, a proposition would need to also cover those or have trade-off with potential new undesired behavior from robots.

saors wrote: Mon Sep 29, 2025 3:30 am That being said, I think you could probably create a cache of all the "from" nodes and "to" nodes. Maybe do some rollups/summarizing based on chunks. And this could be multithreaded - have the bots go to the nearest roboport after picking something up and wait for instruction. But at that point it's becoming much more complex code than just "go straight" for not much gain...

I wonder how it works for trains, if there exist such optimizations, those do pathfinding . But to me ( no expert ) roboport are worse, because not only can they be destroyed or built by bots "fast" like rails but they can also "run out of power" even faster, like every few ticks depending on one's contraption. Trains it's only the signals that can turn on off super fast, it doesn't change "most" of the network. Maybe i'm wroong and it's similar and it's just the number of bots vs trains and the frequency that matters in the end though

saors wrote: Mon Sep 29, 2025 1:30 am But is there any *technical* reason why roboports couldn't make a "linked-list" type of pathing?
I was thinking something along the lines of:
1) use the closest roboport (R1) to try to fulfill the request activating bots
2) If that's not enough, expand to next linked roboport(R2) and try to fulfill the request, etc.
3) each bot would be activated with a "requestId" and instead of instructing "goto (x1,y1)" to pickup entity it would be instructed to goto next roboport in the chain.
4) When a bot arrives at the next roboport, it's instructed the next roboport to fly to.
5) Once it arrives at the original roboport (R1), then it gets the proper instruction as it does today, to pickup item. If the destination isn't within R1 range, use the same method where the roboport does a single pathing calculation to figure out the destination of the object (via roboport links).

In the essence you described A* pathfinding. But your version will try to go in all possible directions simultaneously generating unschedulable calculation spikes. Your concept may work fine if roboports are the processing units forming a distributed network where every node is aware about neighbouring nodes only but PC CPU can't perform such model natively.

Really cool breakdown. The “linked-list” roboport idea makes a lot of sense. Bots just fly straight now, so having roboports handle routing could fix the concave layout issue. Main challenge would be extra complexity (like congestion handling), but in theory it could save CPU and make bot paths way smarter.