Personal robots prioritizing nearest first

[BrickNukem]

TL;DR

(De)construct dense areas faster by having personal robots do the closest thing first, since you can then move around and keep flight distances short.

What ?

Construction bots from your personal roboports have a clumsy order in which they select construction tasks. This causes long flight times. For deconstruction, you can do better by deconstructing small patches and moving around, thereby keeping the flight distances short. A quick demonstration (gfycat cut off the video though):


(takes about 40 seconds)


(takes about 20 seconds)

Why ?

The shown work-around only works for deconstruction. As shown, nearest-first can save a lot of time in late game situations. It's not a big issue at all, but this game is about effective laziness, right?

[Factory Lobster]

This could possibly be implemented as yet another thing to research in the tech tree...

[Terukio]

Love this! Especially with many roboports your range can get very large, nearest first seems like a nobrainer as opposed to what appears to be random. In such a deterministic game, would make sense to be able to predict your own bot movement.

[mophydeen]

rather than see this as a suggestion. I'd say it's currently a bug that should be fixed.

[Manron]

i guess it is the way it is for performance reasons.

calculating which entity is currently 'nearest' has to be calculated every time a single entity is removed or you move.

i dont think the QOL improvement would justify the performance hit.

But maybe i'm wrong here, who knows but the devs.

[Factory Lobster]

Seems like it would be a simple sorting problem. If the sorting eats up processing power then the max selectable area could be decreased.

[malventano]

Uhm, no. It is faster in your second example because you are walking around the area, meaning all robots are moving less total distance to achieve the same deconstruction. If you remain in the center without moving and choose the same sequence of individual areas that you did in the second video, it takes the same (longer) amount of time.

[Factory Lobster]

It is faster in your second example because you are walking around the area, meaning all robots are moving less total distance to achieve the same deconstruction.

I think that is exactly his point. If the larger area automatically started deconstructing the immediate area around the avatar, then he could at least move around while the bots did their thing and the whole process would take less time.

[mp0011]

Simplest solution: User controlled construction zone size. With ctrl-scroll.
User reduce zone size, and bots works exactly as in lower example.

[Factory Lobster]

Simplest solution: User controlled construction zone size. With ctrl-scroll.
User reduce zone size, and bots works exactly as in lower example.

Or bots focus on a certain area around the mouse cursor, as long as it is within the selected work area. If outside, then it switches to its default deconstruction code, whatever that is.

[mophydeen]

Simplest solution: User controlled construction zone size. With ctrl-scroll.
User reduce zone size, and bots works exactly as in lower example.

Or bots focus on a certain area around the mouse cursor, as long as it is within the selected work area. If outside, then it switches to its default deconstruction code, whatever that is.

this will be messy because you move your cursor around a lot. better to use the character position.

[malventano]

It is faster in your second example because you are walking around the area, meaning all robots are moving less total distance to achieve the same deconstruction.

I think that is exactly his point. If the larger area automatically started deconstructing the immediate area around the avatar, then he could at least move around while the bots did their thing and the whole process would take less time.

Agree there. If the player is willing to walk around during the process, that would speed things up.

[BrickNukem]

i guess it is the way it is for performance reasons. [...]

I understand that, but in this case it's trading cpu time for *my* time, so it's worth it to me!

[<NO_NAME>]

i guess it is the way it is for performance reasons.

This could be a problem with stationary logistic site, but personal roboports don't cover that much ground. It should be possible.

Simplest solution: User controlled construction zone size. With ctrl-scroll.
User reduce zone size, and bots works exactly as in lower example.

Maybe even better idea. In addition, when you reduce the area to zero, other players won't be able to troll your robots.

[Hannu]

rather than see this as a suggestion. I'd say it's currently a bug that should be fixed.

This has been suggested many times.

It would not affect performance if only personal bots would seek the nearest target (and also have priority). There are typically far less than 100 personal bots and their searching area is few chunks. It seems that performance hit is common excuse for devs not to do things they do not want to do for some reason. In many cases it would be possible to decrease number of entities (like bots or biters) very significantly and therefore also save CPU time and get more effective and interesting results if they were a little bit more "intelligent".

Maybe there should be 2 separate bot types. Current bots would be simple stupid mass bots for megabases which uses 10000 of them for high volume sorting and transport tasks and there would be more intelligent types for personal building and complex small volume transportations. They could be more expensive and not get cargo bonuses so that there would not be incentive to use massive numbers of them.

[Rseding91]

It would not affect performance if only personal bots would seek the nearest target (and also have priority).

Yes it would. A thing to work on finds a robot not the other way around.

[Engimage]

It would not affect performance if only personal bots would seek the nearest target (and also have priority).

Yes it would. A thing to work on finds a robot not the other way around.

But when you queue up "things to work on" maybe there is a way to put those things in it in a certain order? So you could possibly form up this queue based on certain logic. For example when player wants to deconstruct stuff objects could be queued based on a distance from a player. However this order would remain if a player moves...

Or those things are processed every tick and just cycle through factory objects?

[Hannu]

It would not affect performance if only personal bots would seek the nearest target (and also have priority).

Yes it would. A thing to work on finds a robot not the other way around.

It is just a stupid way to program this kind of thing. Or at least optimizing of some special thing at the price of poor performance in all other tasks. This leads also to situations in which I have tens of robots in my roboport but have to put one power pole manually in blueprinted construcion because it has been assigned to a robot which is out of the power 5 km away because it decided to fix something when I traveled by train.

I understand that you may not want to change it for business reasons. In such case I would appreciate that you would told it and stop requests to change it.

If there were separate "smart bots" for personal roboports, they could behave so that free robot would seek work. If there were be 100 bots and 200 entities in construction area, calculating of distances would take few microseconds but it could save me hours of work in large base. 60 UPS in every situation is not the most important thing in entertaining gaming experience. Avoiding of boring player labor is much more important, at least in my opinion. There should be at least options to minimize player's waiting time instead of maximizing UPS when 10000 bots do high volume transport, which is probably very marginal use compared to building with blueprints.

[BrickNukem]

It would not affect performance if only personal bots would seek the nearest target (and also have priority).

Yes it would. A thing to work on finds a robot not the other way around.

I see. That does make it trickier. Still though, is changing the behavior of personal robots something you are interested in?

[mp0011]

Simplest solution: User controlled construction zone size. With ctrl-scroll.
User reduce zone size, and bots works exactly as in lower example.

Maybe even better idea. In addition, when you reduce the area to zero, other players won't be able to troll your robots.

Also, you could select where construction robots to deconstruct/construct cames from - Your inventory, or the factory.

It's sometimes annoying, when You want to deconstruct something and reconstruct it somewhere else using same materials, but Your bots deconstruct just few elements, rest is waiting for factory construction bots (they are flying from far end of the base, so You wait some time). Then, factory bots grab things You are about to use, and puts it in some distant chest. So You wait AGAIN for that materials to build...

If Your zone is big, Your robots do all the jobs in it. If You want use factory bots, just shrink the zone.