Factorio Forums

Related Logistic Suggestions

I moved the whole logistic network/chest extensions to viewtopic.php?f=80&t=43460 Logistic Network and Logistic Chest Extensions


These suggestions are a little bit "mixed up", cause there is not really a clear line between roboports, roboport-area, logistic-network (and -area) and the robots in that both areas. I'm sorry for that, but it is a game-mechanic, which is very entangled (and it is good so).

First some explanations:
- There is a logistic network, a logistic area, a construction network and a construction area. Logistic bots can work only in a logistic area, construction bots can work only in the construction area.
- All connected roboports built a (logistic or consruction)-network.

Provide and catch back robots into and from a logistic network:
- With v0.12 you can place an inserter to fill in bots into a roboport. Use the robot-combinator-mod (see below), to find out, how many are really needed.
- With v0.12 you also grab bots out of a roboport with an inserter.
- With v0.12 you are not able to order some number of bots to roboports to take the robots out of the network.
- With v0.13 we will be able to connect the circuit network to the logistic network and get robot-count and other info from there. See FFF #123.

(Suggestion: Enable the player to order robots to a roboport, like a requester chest. That enables you to take them slowly out of the network. Same seems to be simple for repair packs. In the end it is nearly the same game mechanics as in Siedler II, where you order knights, swords etc. into towers.)

General suggestions about roboports (mixup)
viewtopic.php?f=6&t=1633 Logistic bot control tower [Very old, still interesting]
viewtopic.php?f=6&t=3202 Some ideas to change Bots mechanic
(and answer: viewtopic.php?f=6&t=3202&hilit=roboport+charge#p23536 - see also down to Robocharge-mod)
viewtopic.php?f=6&t=3551 Custom UI notifications from logistic network conditions
viewtopic.php?f=6&t=4605 logistic questions
viewtopic.php?f=6&t=5348 Bigger, smaller roboports and interstation
viewtopic.php?f=68&t=5748 reassign pending construction robots with cargo
viewtopic.php?f=6&t=6981 Ordering docked bots
viewtopic.php?f=6&t=7993 Splitting up roboport functions
viewtopic.php?f=6&t=8214 "Logistic network"-independent robot recharging
viewtopic.php?f=6&t=13457 Multiple Roboport/Blueprint suggestions
viewtopic.php?f=6&t=14568 Modules for the Roboport
viewtopic.php?f=6&t=25365 Two robo suggestions! [change logistic area size]
viewtopic.php?f=6&t=28985 Allow roboports to snap to logistics net when holding shift
viewtopic.php?f=6&t=34171 filter for roboport content
viewtopic.php?f=6&t=35401 Roboport ideas
viewtopic.php?f=6&t=35516 Multi-purpose (smart) logistic chest
viewtopic.php?f=6&t=37484 Builder Bots



Handling of the Number of Bots in a Network
viewtopic.php?f=6&t=4723 Power and the robots
viewtopic.php?f=6&t=4996 Smarter Robot charging
viewtopic.php?f=6&t=3850 Roboports may request bots
viewtopic.php?f=6&t=5749 Logistic bot network usage statistics [See robotic combinator mod below]
viewtopic.php?f=6&t=8925 Distribution of robots
viewtopic.php?f=6&t=10152 Controlling robot distribution
viewtopic.php?f=6&t=14083 Robot Dropoff
viewtopic.php?f=6&t=18996 Add support for adding and removing robots from network
viewtopic.php?f=6&t=28176 Control Number of Bots in Roboport/RP Content To Circuts
viewtopic.php?f=6&t=41099 Roboport Robot filter
viewtopic.php?f=66&t=45318 Filter in roboports
viewtopic.php?f=6&t=47144 Add auto lauch and request robots ability to roboport



Handling of Robot-Routing / Pathing / Charging

This sub-topic is about problems, when the robot-area is not in a circle shape, but hase more the shape of an "U", well described with this pics.
The general opinion of this forum is currently, that there is not much, that could be improved here by more intelligent routing, cause that means, that the robots need to take a lot more CPU cycles, to calculate that path. Current behavior looks non-optimal, but is not that bad, as it looks (only for the case of U-shaped base, but that should just be avoided or you live with the problems they create. viewtopic.php?f=6&t=3283 Logistic bot pathing improvement
viewtopic.php?f=6&t=12859 Bot Exclusion Zones
viewtopic.php?f=6&t=18082 Let all bots use the personal roboport to charge.
viewtopic.php?f=6&t=23021 Node based pathing for bots
viewtopic.php?f=6&t=21781 Stack size bonus for construction robots
viewtopic.php?f=6&t=26702 Logistics bots should cancel job when request is canceled
viewtopic.php?f=6&t=28325 Roboport option to output construction needs
viewtopic.php?f=6&t=28614 Bot pathing for big bases
viewtopic.php?f=6&t=37761 Roboport waypoint setting
viewtopic.php?f=6&t=38036 Make all bots stay inside their network
viewtopic.php?f=6&t=41361 Construction chests
viewtopic.php?f=6&t=41428 Optimize Drone Movement [explains, why this is not such a good idea]
viewtopic.php?f=6&t=42214 Droids Pathfinding
viewtopic.php?f=6&t=48183 Worker Robots Pathfinding Update (!Important)

An interesting statement from a dev:
viewtopic.php?f=11&t=15234&p=103165&hil ... rt#p103529

Other

The Right Pane / Logistic Info

This will be changed in V 0.15. See FFF #180.

viewtopic.php?f=80&t=17779 Detach Logistic Item Listing From Right Pane [Link Collection Thread]
( viewtopic.php?f=6&t=2583 Logistic network, Storage Infoscreen
viewtopic.php?f=6&t=1222 Logistic overview on the right side
viewtopic.php?f=6&t=4706 Logistics Statistics Screen
viewtopic.php?f=6&t=9957 Logistic System Informational Window
viewtopic.php?f=6&t=13393 Interface For Logistics Storage )

Blueprinting

viewtopic.php?f=6&t=3768 Prioritize Ghost buildings and blueprint construction
viewtopic.php?f=6&t=3868 Player logistic slot improvements
viewtopic.php?f=6&t=22711 Use of a key combination to force personal or base robots to build / deconstruct.

Balancing
viewtopic.php?f=16&t=15109 Build time 0.5s for Logistics/Construction Robots

Defaults for Requesting Items
viewtopic.php?f=67&t=9069 Requester chests should default to zero or one
viewtopic.php?f=6&t=26731 Initial amount of items delivered by logistic system


Mods:
viewtopic.php?f=120&t=14650 Robocharge - Robot Charging Station
viewtopic.php?f=92&t=14388 Advanced Logistics System 0.2.10

Related Logistic Suggestions

I moved the whole logistic network/chest extensions to viewtopic.php?f=80&t=43460 Logistic Network and Logistic Chest Extensions


Other related collections

viewtopic.php?f=6&t=2563 Trains as linkers between seperated logistic networks
viewtopic.php?f=80&t=15326 Stack Filters for Chest, Vehicles and others
viewtopic.php?f=80&t=19987 More Game Information (Statistics, Monitoring, Graphs)

There is an idea for this I didn't see. Giving construction robots a build order / priority:
1 - Deconstruction
2 - Power routing(Poles, Substations, etc)
3 - Roboports
4 - Power generation(Solar panels, accumulators, steam engines and set up parts)
5 - Defenses(Walls, Gates, Turrets)
6 - Other Structures (Assemblers, tanks, etc)
7 - Modules
8 - All other(Flooring, Landfill, etc)

an idea that I came up with on this topic, please reply

I would love to be able to reserve logistic robots for a requester chest or an active provider chest. What I mean is, I want to be able to specify an amount of logistic robots to only the task of filling or taking objects from the specific chest. Robots would be reserved for the chest when they bring or take an item from it up to the specific amount, if reachable. When the robot count is lowered, the robots would become unreserved until the new lower amount is reached. If the amount is raised, more robots would become reserved until the new higher amount is achieved, if reachable.

Yes, see for example: viewtopic.php?f=6&t=41099 Roboport Robot filter, which is the latest example for such a suggestion.

I don't want to create whole separate thread yet I did not see exactly proposition I think of.

Whole idea is not to make robots too smart (like trains require proper signals to work) and yet provide good functionality (if signals are good, routes and behavior of trains is great). We should also take computing power into consideration as robots are counted in thousands.

The biggest problem I found is that robots don't even consider their battery lifetime and they try to fly way further than they can. In real life any algorithm should consider recharges. My proposition is simple and would fix most of problems. Of course it does not fix flying over enemy territory but would improve that as well.

Currently robots just fly out to destination and go to nearest station if battery is drained. Change I propose is to plan charges ahead. I'd list all steps needed for that but there is actually one new step. Depending on current implementation it could even improve performance of huge logistic networks.
Logical side:
1. Destination is in reach?
true - fly there
no - fly to reachable roboport that is closest to destination
2. When you reach this roboport go to 1. Either go straight to destination or get next reachable roboport that is in range.

Algorithm side:
I don't know how it is implemented right now, so it's hard to tell. Surely you have some collection of roboports as you need to know which one is closest to robot for charging or docking. Maybe you mapped roboports to tiles so at each position you know roboports in range. I don't know.
One way of implementing that would be keeping list of roboports in range of each roboport. That would not scale good with good networks but would have best performance. This way even with huge networks you have just a bunch of roboports in radius of constant flight of fully charged robots. Those are roboports you can reach without recharging. Now if distance to destination is higher than robot range, you have this bunch of roboports that are in range. Just check which one is closest to destination and fly there. Don't even plan how you will fly afterwards. Check that when you are charging. This way not matter how long flight it would be, you have the same number of processing to do.

Possible problem of this solution would be getting stuck at one roboport when your network requires flying back and around. Just like some penisula which has closest roboport to other side or sea but is still too far away. In this case your starting roboport would be the closest one. You can simply go back to old mechanism when this happens. Fly straight to destination and at some point you will either reach it or stop for charging somewhere going back to new mechanism.

Other solution would require planning whole route ahead but it has some problems. Route may change (new roboports or some removed during flight). It would also add some processing for each long flight. I think limiting to closest roboport would be optimal idea.

Now comparing it with the case from images above. Let's assume basic robot with 3m/s. It holds 1,5MJ, uses 3kJ/s (hence 1kJ/m) and 5kJ/m travelled. Sum it up and you have 6kJ/m on full speed and 250m range on full charge. Maximum distance between stations diagonally would be around 70m so it should be able to through 2 stations at least before charging at 3rd.

Let's visualize it on the same example as above images.

Simple case.
1. Take closest to Z roboport within flight range.
2. Z is in range.


The same with smaller flight range.
1. Take closest to Z roboport within flight range.
2. Take closest to Z roboport within flight range.
3. Z is in range.


Now the problem I mentioned.

Original implementation:
1. Go straingt to Z.
2. No energy, slowly go to closest roboport to charge.
3. Go straingt to Z.
4. No energy, slowly go to closest roboport to charge.
5. Go straingt to Z.
6. No energy, slowly go to closest roboport to charge.
7. Go straingt to Z.


Proposed solution with simplest fallback mechanics (if Z is not in destination and yet we are in closest roboport, fly there anyways).
1. Take closest to Z roboport within flight range.
2. Take closest to Z roboport within flight range.
3. Take closest to Z roboport within flight range.
4. Fallback, fly straight to Z.
5. No energy, slowly go to closest roboport to charge.
6. Z is in range.


Extended fallback that extends search radius to find closest roboport that would also be closer to Z than current one.
1. Take closest to Z roboport within flight range.
2. Take closest to Z roboport within flight range.
3. Take closest to Z roboport within flight range.
4. Fallback, take closest roboport that is also closer to Z than current one.
5. Z is in range.


As I mentioned, it would also be possible to plan whole path ahead but it would be much more complicated. Then it would take route around the water instead. I think my proposal is sufficient, it greatly reduces robot stupidity and is still fairly simple.

Also I mentioned that it will not fix problem with flying over enemy territory but it actually might improve that behavior. This way robots will try to stay within fast flight range from roboports, so they would not try to fly directly through unknown territory. Instead they would jump along the route.

Why this solution seems most reasonable to me?
- Despite more calculations for robot routing, it is limited only to first "jump" robot makes. Currently each time battery dies algorithm has to find closest roboport to robot coordinates. This solution removes that need and instead each time requires finding closest roboport to Z that is in range. To make it less CPU hungry rach roboport could keep some list of ports in range limiting how much checks will be done. Such list will also be pretty easy to handle. If you create new roboport, list all ports in range. One time action. Of course each roboport in range will have this one in range as well, so add them to their list. While removing (disabling) roboport you already have a list of those in range, so just follow it and "unsubscribe". The point is that it should have similar performance to current one regarding robots behavior and would only add some performance loss for creating and removing roboports. Also memory usage should not be that bad unless you have hundreds of thousands of roboports.
- Compared to solution showed by @ssilk it does not stop at each roboport on the route. Just when it's needed.
- It surely depends on implementation but it should be fairly simple to implement, so less risk of introducing new bugs. If currently each robot holds one target, then it would have to hold final destination as well as current target, so it could update route after charging. Despite that only collection of roboports in range and logic behind it would be necessary.

Moreover for charge balancing you can use variation of current mechanism.
Currently it considers distance from robot to closest roboports and queue for charging with some ratio of queue size vs additional distance to charge.
In my proposal you can use almost the same mechanism. If choosen roboport for charging has queue over X, then consider next one that is a bit further from destination. This way in case 100 robots fly on the same route from one container to another, they would split into several groups charging at different ports, even taking different routes. After first charge they will not be one single pack but several smaller ones which will be easier to charge. It's necessary to see such thing in action to tell if it works as expected.

So I was thinking about the routing issue, and it dawned on me that a simpler way to approach it might be to use something similar to what's already in place for the train pathfinding.

If you have each logistic network defined as a Zone, then you path Zone center to Zone center until you hit the target Zone, then go to destination chest.

When you place a logistic chest, it should gain an identifier something like [A.1] - it's chest 1 in Zone A. In the case of overlapping networks, the zone designation goes to whichever Roboport is closer.

So let's look at an actual network here:

So right now, I have a logistics bot flying direct from D.3 to F.1. Sure it's quick until we get into the situation of the bot being out of juice and needing to detour for a recharge. Now, yes, this is all in nice and close together, but the principle here should be the same. The bot should be looking at the path along the connection lines already established - D.3 > D > C > E > F > F.1 - instead of flying direct from D.3 > F.1.

If we want to take it a step further, set a toggle in each Roboport to define bot behavior in that zone - direct or point-to-point. If I set direct, then I should be seeing the behavior I'm seeing now. If I set point-to-point, any zone transition causes the bot to travel to the zone center before going to the next waypoint. For adjacent zones with different properties, the bot adheres to the new zone's rules. For example, let's say A, B & F are set direct, C & E are set point-to-point. A bot traveling from A to F will cross into zone C, so it will go from A to the center of C, then to E, then to the destination in F.

This is just my two cents, but I think that will greatly help us reign in the insanity we see with the bot networks and also give us some ability to streamline operations. But really, we just want to get away from this:

I know what two points led the bot to be out there, but come on...

Interesting thoughts expressed here.

First, let me start by agreeing that construction robot prioritization and pathing needs some tweaks. I've seen the following problems:
1. Infinite loops caused by closest recharge available being in the wrong direction (i.e. huge gap, robots go out, then come back to the same place again to charge)
2. robots being killed by pathing over monsters (i.e. ALL BASES MUST BE RECTANGULAR)
3. robots waiting ridiculusly long times (sometimes infinite, depending on bot supply) for removal of trees so they can place their belts or whatever.
4. robots constructing things in the wrong order (i.e. placing the laser turrets before the power poles are place, then biters destroy all the turrets easily)
4a. robots constructing random shit instead of the power poles to the next roboport (which would engage another few hundred bots to construct the next section) resulting in vastly inflated construction times.
5. Bad interactions between personal roboports and building-type roboports. (Specifically, the building type "claim" the deconstruction, and then I'm standing right there with the materials and have to chop trees BY HAND even in extremely-late endgame, because my robots won't do it, and the building-type ones will take five or ten minutes to get there.)
6. Quasi-random choice among ghosts in range of what to build. (Seriously, put four or so personal roboports mk2 in and build a large blueprint of tiles or grid of traintracks. The order in which things are built makes NO sense. Upper left to bottom right, but in rows? Madness. And so obviously nonsensical that it's immersion breaking.)

There are a few subtlties that you've missed. Primarily that there are personal roboports too, and charging isn't (currently) calculated as a matter of finding the *closest* roboport, but of finding the fastest charge, accounting for distance & number of robots already waiting to charge.

So your

Bonaducci wrote: ↑Sun Jun 02, 2019 10:50 pm The biggest problem I found is that robots don't even consider their battery lifetime and they try to fly way further than they can. In real life any algorithm should consider recharges.

is I think accurate, but incomplete. You'd need to tweak your proposed algorythm by "closest/fastest charge, accounting for distance lost (both going to charge point and time lost going AWAY from target) and number of robots waiting, etc." Otherwise, you could place a cluster of roboports at points where there's high bot traffic, and the robots would all try to charge from the same roboport ANYWAY, and you'd have gained nothing.

Also the proposed priority list is incomplete, and won't fully fix things anyway. The following things need to be considered.

1. Robots must eventually get there. Even sub-optimal setups should at least work eventually.
2. Personal roboports MUST be able to usurp jobs, but shouldn't do so if the robot that is assigned is in visual range (approximately)
3. Personal roboports ESPECIALLY should prioritize removals that allow placement for items that are available.
By which I mean that if we don't have any solar panels, removing the trees to allow solar panels to be placed should be a low priority.
4. Distance MUST be the primary determiner of job priority, as it's what actually takes not only time, but grid power (which is always in short supply)
5. Placing things that allow the roboport network to expand need high priority
6. Placing & repairing defensive structures (laser turrets & power to them) need high priority

I'd like to elaborate on #1. Right now, the construction and logistic network is very opaque. There's no way for a player to point at a pipe ghost and find out if there's a robot assigned, where that robot is, how long it'll be, or anything at all. Even the chests only give a number for pickups scheduled, and give no clue as to final destination or where (or whether) the robots are stuck.

If we had some debugging tools (some way of finding the wayward robots) it might be acceptable to have the robots get stuck in infinite loops. But espeically a novice player won't have any idea, which winds up just being pointless frustration. If somebody's done something wrong, we need to TELL THEM so they can fix it, not "wait forever and nothings happening, but I don't know why or how to find out."

i.e. poor gameplay experience.

Because of #3 & #4, the priority building list cannot be laid out perfectly, and at each stage we need to ignore things that we don't have (don't prioritize removing trees for large electric poles if we don't have any large electric poles) as well as figure distance into our plans.

However, this is my list:
1a. removals for electrical supply
1b. Building electrical supply
2a. Removals for defensive structures
2b. Defensive structures (walls, turrets, radar, just like the game)
3a. Removals for roboports
3b. Roboports
4a&b. Eletrical generation (solar panels & accumulators, mainly, but also pumps, pipes, boilers, tanks, steam consumers, etc.)
5. Everything else

Because of #4, this list cannot and should not be followed exactly, but should instead probably be applied as a multiplier to distance to make a priority queue. Ghosts close to the passive provider chest containing solar panels should get built first, darn it! Especially as this means that the robots will have more charge points available, multiplying it's effect on total build time.

However, if the game really has an internal limit of 600 jobs to consider, this is all moot - placing a solar array of 100 roboports overwhelms that so far it's not even funny.

Honestly, my main frustration is to be stuck chopping down trees with a frickin' *AXE* when I've launched a few thousand rockets. It's ridiculous! (see item #2 of first list.) I am a veritable technological GOD! I shouldn't have to chop my own trees!

How many times have you observed this: The robot flies to the target to repair or build / deconstruct something, but does not reach one or two cells, turns and flies to the roboport to charge... Or it flies into the middle of a huge lake... Or even worse right on enemy base.
Here's what happens:
The robot gets an assignment leaves the roboport and heads towards the destination.
When its battery decreases to a specific value an event called "need to recharge" is triggered. The robot instantly changes his route and heads to the nearest roboport.
After recharging, the robot again goes directly to the target.
The extra mileage traveled by the robot, however, is not taken into account, no matter how many zigzag pattern it makes during its travel.

Solution
Adding a simple calculation of real route length would solve the problem of "dumb robots". In this case, the same calculation methods that are used in the game now will be used. We add only a couple of checks and a few mathematical steps (provided that the flight distance is greater than the distance before the charge is lost) to calculate the coordinate where the event "need recharging" should occur in advance.
Adding a single one-time check on the distance to the target we get:

• No need in triggering the event "need to recharge" during travel towards the destination.
• Straight travel patterns between the roboports with "normal" and L-shaped bases !!
• Increased CPU load with U-shaped bases in cases when hundreds and thousands of robots will be receiving a roboport as a new destination where to get recharged in.

To solve the problem with the load on the CPU, we add a test for the similarity of the roboports and the available charge with the maximum. If the new roboport corresponds to the roboport of the robot and the robot is charged, then we set the robot the status of "waiting" (for example, 10 seconds of inactivity).
If you wish, you can add an alert to players about the presence of such robots in the form of an alarm and / or the flying text “There is no direct path to the target” sent by the roboport (crowds of waiting robots will accumulate at one roboport).
There is another ready-made solution
For a more optimal solution, it is necessary to consider a network of roboports. Search for the nearest roboport at the target (read the roboport of the target) and send your roboport a request for receiving the coordinates of the roboport along the way.

I going through the suggestions here and I want to add, that the obvious solution isn’t practical in reality.

Say we have a lake like above and want to expand the base, suddenly hundreds of robots need to fly the long path around the lake. They will starve at the completely overwhelmed roboports, waiting for charge.

If they instead take the direct way over the lake, they “cheat”. They don’t need that much energy and instead of waiting for recharging they just fly slower. In the end this can be much faster as the way around the lake. It depends.

Another situation is, that the lake is just so large that flying around just makes no sense. But a beginner will eventually not come to the idea to use landfill and place some roboport to make a path for them.

What I want to say is, that the obviously correct solution isn’t always the best.

ssilk wrote: ↑Sat May 23, 2020 7:29 am Say we have a lake like above and want to expand the base, suddenly hundreds of robots need to fly the long path around the lake. They will starve at the completely overwhelmed roboports, waiting for charge.

In this sense, the situation will not change. Requires the installation of additional roboports for recharging on the coast. After the innovation, the robots will recharge at the same roboports as before.
The essence of my proposal is that robots fly between roboports in a straight line. At the same time, a special case of the “turn” of the robot, which almost reached the stationary target, will be corrected.

ssilk wrote: ↑Sat May 23, 2020 7:29 am If they instead take the direct way over the lake, they “cheat”. They don’t need that much energy and instead of waiting for recharging they just fly slower. In the end this can be much faster as the way around the lake. It depends.

But there may not be a lake, but an enemy base.

ssilk wrote: ↑Sat May 23, 2020 7:29 am Another situation is, that the lake is just so large that flying around just makes no sense. But a beginner will eventually not come to the idea to use landfill and place some roboport to make a path for them.

Now, in some cases, when building a U-shaped base, robots fly back and forth recharging at the same roboport. A beginner will not be able to guess that robots cannot achieve the goal in this situation. Therefore, I suggested making an alert.

ssilk wrote: ↑Sat May 23, 2020 7:29 am What I want to say is, that the obviously correct solution isn’t always the best.

It is possible that the load on the CPU will increase slightly. At the same time, the distance traveled by robots will decrease, which means that the execution time of each specific task will decrease. This will reduce the number of robots needed, which will slightly reduce the load on the CPU. This is not obvious, but the effectiveness of robots will really increase.

Consider a special case inside the base:
When the forced recharging position is between the roboports, the least busy nearest roboport is selected.

It is still so, that this idea is not always the best. There are situations, where the optimal behavior is the current. It depends on the dimensions and shape of the hole where the robots needs to fly around.

And - I know this argument will open up a big discussion, but eventually the bigger issue - the estetical element, when you place/remove a lot of entities and the robots come out of the roboport in a row and build some interesting lines on screen is partly removed. That removes also a lot of fun to watch the robots. But this suggestion handles a situation which is not so common and it could be seen as part of the gameplay to handle the problems evolving from it.

Edit: the decreased distance of flight path length will be eaten up by the players, that use then more robots.

I’m not against this, but the nature of this change involves the Devs. And their priority of this it is surely very low.

So i have the problem currently...

I have a large main base which is full coverd by roboports, but then into the wilderness, my roboports follwos along ores/rails, so the gernerall layout is there or a root system which much space between the branches....
So occasionally some robo will try to travel between the branches, but can not because of energy.

I understand the underlying mechanic, but i would suggest, that a robo which travel to and fro the same roboport( an reasonable number, say 2), (which is an indicatior that he can't use this way), will try for an other robobort as recharge point....
I mean this would a simple solution and not be a big impact on CPU/Memory, because you only need a counter and check if starting roboport is the target.
But at least the robot has a change to succed his journey because he will use an other roboport as staring point....

Well, I know that this is also kind of taste, but I still believe that robots shouldn’t be used for so far distances. I think their limits in vanilla are around 1000 meters radius around some kind of “center”. And that optimum depend also highly on the number of robots and number of roboports.

You can use them differently. Of course. But then the problems like this arises. And this problem with pathing is just one of them.

(In my opinion the better strategy in that case is to make a new roboport network. Don’t connect it with the main network, instead make transfer of items between them by train, or yourself or make a transfer area, where you connect the networks by requester/provider chests and inserters.)

Yes i know this all
Tried different approches - still no super fan of robots, because they take out a large chunk of the puzzeling of factorio....

Its just comfortable later in the game when the thirth ore patches runing dry, so place down the the rails, the roboports, the miners and all whats not all.
Its no prolem if the robotarmy takes hours of completing.

The problem aries much then wenn trees needs to be cut down for placing and then the robot from the other branch will be assigned to do it and it cant go to work -theses pure creatures.....
currently trying to breadcrump a line of roboports to help this, but if for the new roboports needs to be some choping, so it could have only shifted

Thinking of that....
Other solution could be if a task is not completed by certain amount of time, it could be assigned to an other robot(still not a perfect solution, but maybe the other robot is placed better ?)

Thinking further - one could make the robot range infinitely resarch; maybe with an drawback to speed then ?

For a "good" visualization, it may be worth sending robots directly to the target, if necessary recharging dramatically change the trajectory. Thus, the scatter of robots on the map is really large.
Any perfectionist after noticing the robots flying in zigzags will say: “What the hell are they not flying in a straight line ?!”
Those who do not want / cannot get rid of enemies close to the base will say: “What the hell are they flying to the enemy base ?!”
I relate to both.

Moving a little away from the topic: I propose that robots fly out of the roboport not at one point, but make a small spread - this will be much more aesthetic.

I am not saying that my offer is the best. But implementing the solution is very easy, just like fixing a bug. That is why I called it a “ready-made solution”, because It uses the existing code in the game.

There will be both supporters and opponents of this change. You can add the inclusion of this change optionally. Calling the option "Flight of robots between roboports in a straight line." By itself, the disabled option will not affect performance in any way.

have this issue too I see why it hasn't been implimented but i fall into the can't remove emeny's from around my base catigory because that is what my robots are trying to do place turrets and stuff but all in the wrong order and by flying to the wrong spots and over enemy bases. My hopes are they make this an option or soeone make a mod.