Factorio Forums

ssilk wrote:... how it helps to solve the problem mentioned in this suggestion. I would also say it's a bit off-topic.

If correctly placed it will just change robots route, because new magazine will be avaible for robots.
Using firs post map:
S produces for example silver plates.
W got this new magazine, robots deliver there.
E robots chose to pick from W as W is closer than S

But the problem is: How will bots bring the items from E to S. Your solution doesn't help anything, cause items need to be transported from E to S. You cannot force the bots to bring it to W first, there will be some left, which will be transported directly.
... completely off-topic.

I think my solution will work as this magazine can store a lot of items. Ofc on start it will not work, only after magazine gets desired item amount.

"How will bots bring the items from E to S."

It will bring needed items from E to S using W magazine :p
I will do the test and tell if this works.

Tested, but without super big base (have hard to make it bigger due to not peacful aliens).

Robots try to deliver from "E" to "S" and "W" at once. Robots fail to deliver to "S" so they back for rechearge. During this time order gets refreshed and robots from "W" delivers items to "S".

I never have the desired amount of items in my chests.

Oh, I always got too much items, so I guess I got another perception
Did the test, should work I think. (edited last comment)

ssilk wrote:

TheSkiGeek wrote:It feels like it wouldn't be too hard to compute optimal paths between all the roboports, since it only has to be updated once each time a roboport is placed. You could potentially do it lazily in the background for the existing ones when a new roboport is placed.

Theaoretical yes. Practial they don't go to the next roboport, if it is too crowded. The formula is simple: Use next roboport If distance to roboport in tiles is bigger than number of waiting bots.

So the "shortest path" currently changes with the amount of bots waiting for charge and it can be awaited, that such a very useful behavior will be in a reworked pathing algorithm.

Which is quite difficult (as I already stated). So I would not put more brain into this suggestion. It needs to be changed, yes, but we cannot tell the developers how.

Instead we should tell the the WHAT. What would I like to do, what is annoying etc. But I don't see new insights in this thread till now, everything already discussed.

Ah, yes, you would ideally need to take charging into account as well on long trips. But if they are guaranteed to path such that they never fly far enough from roboports to get stranded without charge (which what I suggested would do), then the existing charging behavior might be enough.

I've seen it suggested that the bot pathing is "dumb" because its computationally infeasible to do optimal pathing on a per-bot basis. I don't think pointing out ways it could be done efficiently is a bad idea!

Yep, keeping robots in "green area" would be enough to go to nearest robopot after losing energy.
But the question how much it is complicated thing to do.

To resolve issue posted here it should be enough to pick nearest roboport to the bot not among all roboports, but only among roboports that are closer to the target than the last roboport bot has visited (when departed or recharged). It may theoretically add some discharged slow travel if that roboport is far enough but at least bots will advance towards the target.

Harkonnen604 wrote:To resolve issue posted here it should be enough to pick nearest roboport to the bot not among all roboports, but only among roboports that are closer to the target than the last roboport bot has visited (when departed or recharged). It may theoretically add some discharged slow travel if that roboport is far enough but at least bots will advance towards the target.

Pretty much

ssilk wrote:But the problem is: How will bots bring the items from E to S. Your solution doesn't help anything, cause items need to be transported from E to S. You cannot force the bots to bring it to W first, there will be some left, which will be transported directly.
... completely off-topic.

Also - my post lost the formatting - the starting area was the +, while W was the west extension. To move stuff from E to S the bots will have to travel via +

Is simple, restrict bot movement along the lines of the roboport connections, once they get to the final robo port they are allowed to leave the "bot railway" and do other stuff, once completed, they return to the nearest port. having the invisible "railway" would also save on processing power as each bot is not pathing itself, its just using a path that already exists and then does a little bit at the end.

Port to port roboport movment has been sugested before. Devs are keen to keep the point to point movement though, the roboport only becoming a point if it is needed for recharge or docking.

Natetron01 wrote:Is simple, restrict bot movement along the lines of the roboport connections

How would they go from S to E in that example? They would not be allowed?

Even disreguarding path finding, I consider it bad practice to have a single big logistic network.Bots are nowhere as capable as train when it comes to speed, volume and endurance, and the logitic system can't predict your needs anyway, so bots may take a lot of time to go where they are useful when they are useful if the base is too big. For big bases, I'd say fragment your logistic system ad help it with trains.

What I used to do is make what I called "Robo Antennas". Imagine a very wide U with roboports at the tip of both sides of the U. Bots pathing from one tip to the other would try to go straight across, run out of battery, and repeat. I would make a line of roboports coming up from the bottom not quite as tall, and near enough to the edge so that bots trying to go from one tip to the other will go towards the antenna instead, and then additional smaller antennas if needed to get them going along the bottom.

Best bet though is to spit up that network at the moment. Although I agree a simple sanity check wouldn't be game breaking... If a bot keeps going back and forth then head to the average middle of the logi network for x meters and try again. Or head to 2nd nearest roboport etc.. But then, I'm not a programmer so can't really say.