Personal robots prioritizing nearest first

[Qeeet]

For now construction robots almost always start off from far objects. Could it be improved so that they search for the nearest object to work with?
Or at least to be able to change theirs behaviour.

[Koub]

[Koub] Merged into older topic with almost identical suggestion (personal vs all bots). Both share the same mechanism so merging is relevant.

[slippycheeze]

Just ... throwing my voice in the ring, I guess. I turned off the "Closest First" mod that implements this (via horrid hacks, oh, my, gosh), and discovered just how bad the default behaviour is. Suddenly robots ... just ground to a halt, from the personal roboport. They didn't seem to get anything done, it took so long.

The hack, of course, is to adjust the size of the construction are of the roboport down while robots are busy, and up when they idle, which has issues ("make sure you don't have busy robots and remove this, or it'll stay small"), and costs for polling to answer "are they busy", and relatively slow reactions.

Approximately closest first would be such a win, and ... honestly, it just felt really bad. It wasn't just that it was slow, it felt like my robots were suddenly wildly underpowered.

[GotLag]

The bot tile placement improvements in the latest FFF are interesting, but for placing entities I think it would help a lot of bots originating from a personal roboport prioritised construction based on distance.

It would make placing rail tracks from a train much quicker, and would allow players to speed up construction of blueprints by moving themselves around as they're built.

[ssilk]

There is a mod for that https://mods.factorio.com/mod/ClosestFirst , but it removed it, cause it was not stable, then there are also reasons, when you want to place farthest first, and it took a lot of cpu.

[Koub]

[Koub] Merged into older topic with same suggestion.

[Sismodium]

TL;DR

Even with the advanced AI construction bots are perceived to have have to construct things, they do not have the intelligence to work efficiently. A small rework of drone AI would make bots seem much more intelligent and work systematically.

What ?

What I am suggesting is that instead of a drone flying from the player right to the edge of the control zone and passing 10-20 blocks of the same resource, why not have the bots build the closest things first and work out?

We all know what would happen using bots here...

But it would be much better if the bots worked from close to far, a systematic approach is far more believable for modern day AI.

Why ?

Honestly, I think the small change in how the bots "think" would make the game, and the use of bots with AI much more believable.
As a real life example compare robot vacuum cleaners from 5 years ago to robot vacuum cleaners today. 5 years ago they worked in chaotic lines and eventually covered all the carpet if you let them drive for long enough. Today they are systematic and cover a floor row by row or column by column.

[Koub]

[Koub] Merged into older topic with same suggestion.

[Néomorphos]

too much cpu cost for cosmetic use (or edge-cases uses)

TL;DR

Even with the advanced AI construction bots are perceived to have have to construct things, they do not have the intelligence to work efficiently. A small rework of drone AI would make bots seem much more intelligent and work systematically.

[malventano]

too much cpu cost for cosmetic use (or edge-cases uses)

Except it's a very real difference in build efficiency. Way beyond 'cosmetic' or 'edge' cases. The closest first bot mod has over 30 thousand downloads, and that mod isn't even that CPU efficient, so clearly plenty of folks were willing to trade one for the other.

[mrvn]

CPU wise it's also a big differnece if you are talking roboports or personal roboports. While the feature would be nice for roboports too it is much more noticeable for personal roboports. And there usually aren't 100000 personal construction robots around so the CPU cost is rather negible even if closest-first takes two or three times as much.

As mentioned earlier the greater cpu cost also has to be weight against the faster build time. So even if the game runs 10% slower while constucting it will finish more than 10% faster. The extra time spend per tick will probably more than made up by the reduction in the number of ticks needed to finish building.

[Rseding91]

CPU wise it's also a big differnece if you are talking roboports or personal roboports. While the feature would be nice for roboports too it is much more noticeable for personal roboports. And there usually aren't 100000 personal construction robots around so the CPU cost is rather negible even if closest-first takes two or three times as much.

As mentioned earlier the greater cpu cost also has to be weight against the faster build time. So even if the game runs 10% slower while constucting it will finish more than 10% faster. The extra time spend per tick will probably more than made up by the reduction in the number of ticks needed to finish building.

If the player doesn't move there is zero gain to do nearest first. So having roboports do nearest first is pointless.

Doing nearest first for a player *only* has benefit if the player keeps moving.

[5thHorseman]

Doing nearest first for a player *only* has benefit if the player keeps moving.

Which - admittedly - happens quite a bit. Especially if said player is moving closer to things so his robots will do them first.

[malventano]

Doing nearest first for a player *only* has benefit if the player keeps moving.

It's not just about the total time to completion. It's about the rate of completion. Even with the player standing still, significantly more items are placed earlier and faster with nearest first at play, which leads to more items being placed before bots need to charge, and in the case where the player was low on battery power, means more can be placed before the player is out of juice, meaning that significantly more of that blueprint can be placed before the player is forced to manually complete the remainder. Additionally, when faced with this 'out of juice' scenario, the bots slated to place the remaining items will be at a random place in the recharge queue and must wait behind other bots that are finished with their work, forcing the player to wait even longer for completion.

Even without the rate consideration, there are also 'middle' scenarios which prove Rseding's statement to be incorrect: With closest first at play, the player bots could have completed placing an entire blueprint and the player then running out of battery power as those remaining long-path bots were returning and recharging. Without closest first, random portions of the blueprint would not be placed when power ran out since the bots required recharging earlier in the process.

This effect is amplified when cutting and pasting, as the bots will first clear the closest area, and then again place in the closest area that was just cleared.

All of the above also applies to non-player roboports. Yes the total time will be the same, and there are no batteries to run out, but significantly more of the blueprint will be placed in a shorter period of time, which also means lower average active bots on the map (fewer bots flying to place the remaining remote items).

Which - admittedly - happens quite a bit. Especially if said player is moving closer to things so his robots will do them first.

...and it would happen even more if personal bots were completing the nearest items first. The player would naturally walk over to the uncompleted portion (to assist with the build) and would then indirectly speed up the process.

All of the above (closest first + some player movement) leads to significantly higher efficiency, where this was previously not in the player's control.

Lastly, the current mods that attempt to accomplish this have to do hacky workarounds. If this were coded into the game engine, it would be significantly more efficient and would probably result in an overall net gain to UPS given more bots would be completing more of the intended action in a shorter period of time.

[ssilk]

If the player doesn't move there is zero gain to do nearest first. So having roboports do nearest first is pointless.

Doing nearest first for a player *only* has benefit if the player keeps moving.

I don’t know what’s the base of this thought, but due to my experience and tests it has some advantages to do the nearest first in some situations.

First we need to distinct, if your blueprint/ghosts are
A) completely covered by a roboport area
B) partly covered by roboport area
C) not covered at all

For A and B we also need to look, if all needed items are available in the logistic network, before doing stuff with personal roboport. It should place things, which are not in the logistic network first.

So if C is the case, then it makes lot of sense to construct nearest first. Reasons:
- as malventano mentioned: for small blueprints they can do more, until they first need to load.
- player sees more, the visual feedback is much more satisfying.
- If you are in the middle of a forest and want to “break out”...
- it is much more calculateable what is build first. That is especially important if you are in the outback.

For B this picture changes. Here I want to built first the parts, which are NOT covered by roboports. Which are likely to be more outside. But still want to have first the trees in my surround removed, than far away.

And for A it should place preferable that items that are not in the logistic network. But also prefer to have first trees around me removed.

Summary

Situation A
- first help to remove items, preferable nearest first
- place items, which are not in logistic network, far first
- place remaining items, near first

Situation B
- first help to remove items, preferable those in the outside of roboport range, far first, then those around me, nearest first
- place items outside of roboports range, far first, because a new roboport might reach the near area
- place items, which are not in logistic network, far first
- place remaining items, nearest first

Situation C
- remove items, nearest first
- place remaining items, nearest first

Even if the difference might not be very measureable, this will work much more satisfying, than yet.

So generally it’s the algorithm described in situation B, which can be used with small modifications for all cases.

[bobucles]

I think roboport priorities can be best resolved by letting players set their desired roboport radius. A tighter radius definitely launches bots on shorter errands and they work more efficiently as a result. Some quick modding with -5 radius on the mk.1 and mk.2 definitely gets the bots working more quickly.

[mrvn]

CPU wise it's also a big differnece if you are talking roboports or personal roboports. While the feature would be nice for roboports too it is much more noticeable for personal roboports. And there usually aren't 100000 personal construction robots around so the CPU cost is rather negible even if closest-first takes two or three times as much.

As mentioned earlier the greater cpu cost also has to be weight against the faster build time. So even if the game runs 10% slower while constucting it will finish more than 10% faster. The extra time spend per tick will probably more than made up by the reduction in the number of ticks needed to finish building.

If the player doesn't move there is zero gain to do nearest first. So having roboports do nearest first is pointless.

Doing nearest first for a player *only* has benefit if the player keeps moving.

And you truly believe players will not keep moving when it gives them such a great boost to construction bot speeds?

Hell, I would even automate this in the true factorio fashion and stand so that I'm on a transport belt and get carried through the blueprint as it gets build automatically.

[netmand]

Doing nearest first for a player *only* has benefit if the player keeps moving.

Which - admittedly - happens quite a bit. Especially if said player is moving closer to things so his robots will do them first.

We should consider that all construction bots address the work when construction zones overlap. Many of you may have seen where construction can occur quickest with just the construction bots in your inventory, but for some reason the work is partially done by other construction bots from other roboports nearby.

Also, no one has mentioned calculation anomalies in dispatching that cause delays for some bots. An example of this happens when bots can move faster than you run(i.e. Worker robot speed 10+); try setting up a long rail line (like over 500 rails) and run along the ghosted path. Eventually the bots pause laying rail all at once, then they start coming out in bursts. My short description here is poor, you should try it to see what I'm talking about. It's an example of how to dispatching behavior changes and that bots don't necessarily start moving as soon as the work is laid. To me there's a lot going on with bot dispatching. Plus given this example, I don't want nearest first, I want first in so I can keep running along.

You may not want nearest first when something is in the way, you want that tree harvested first then the item laid.

When I'm clearing forests I laugh when that one tree is on the opposite side of where I'm moving to next, so I have to wait for one bot to harvest one tree in the wrong direction. I can't complain, bots don't know I'm moving to the right.

So in the end you want to make construction bots smarter, right? But now look at all you have to do to program them. This intelligence may be too costly, what if to maintain game performance we can have our intelligent bots but then we're limited to a super-tiny amount like 10? Personally I'd rather have limitless dumb bots with performance impacts in the order of thousands of bots versus not being above to have a 5th bot because my computer is 15 years old. Of course I'm exaggerating but I hope you see my point. If making bots smarter comes at the cost of the number of bots we can use and game performance, is it worth it? Is nearest first such a big pain that you feel they should make the game more expensive?

[coppercoil]

I want nearest first. Sometimes I place large/huge blueprint and want some important parts to be built earlier (e.g. turrets or key electric poles).

[mrvn]

You may not want nearest first when something is in the way, you want that tree harvested first then the item laid.

When I'm clearing forests I laugh when that one tree is on the opposite side of where I'm moving to next, so I have to wait for one bot to harvest one tree in the wrong direction. I can't complain, bots don't know I'm moving to the right.

If it is in the way then you are running up against it. It will be nearest and the tree that is blocking you will get felled by the next bot available.

So really nearest-first will solve your problem of trees blocking you too. So you want nearest-first, too, or do you want to be blocked?