Personal robots prioritizing nearest first

[Rseding91]

It's not going to happen.

[malventano]

It's not going to happen.

...so you stated why you believed it was useless, then folks explained why that belief was incorrect, and then you just cross your arms and shut it down instead of making any sort of counter argument.

It's really puzzling when such amazing devs can just randomly turn on their own track records. Spend a decade making a game better in all sorts of ways, optimizing everything, but then shutting down other great ideas that would make the game even better, for 'reasons'. Tougher problems than what is in this thread have been solved in elegant ways. What makes this particular optimization more impossible than those other things that were previously improved?

How about meeting the community halfway and exposing some more of the bot logic so that mods can implement closest first in more CPU efficient ways? You've made such tweaks for your own mods to work after all...

[Rseding91]

I don't need to make a counter argument. My original statement-of-fact is still true and nobody has shown otherwise: closest first is pointless if the player does not move.

[mrvn]

I don't need to make a counter argument. My original statement-of-fact is still true and nobody has shown otherwise: closest first is pointless if the player does not move.

Your "statement-of-fact" is based on the assumption "player does not move". That assumption is plain wrong. The player moves. The player is even intelligent and moves intentionally and learns and finds the best way to move. If moving around a blueprint hastens the construction then players will very quickly learn to move in such a way as to optimize build times.

As you can see if you watch anyone using one of the nearest-first mods.

[malventano]

I don't need to make a counter argument. My original statement-of-fact is still true and nobody has shown otherwise: closest first is pointless if the player does not move.

Then you didn't read my reply. There are cases where it takes *significantly* longer to complete a blueprint placement without closest first, even with the player remaining still (player runs out of power near completion), and there are also significantly more items placed earlier in the process with closest first. Your statement-of-fact is easily disprovable simply by observing the two types of operations side by side.

Aside from the above, the player *does* move, constantly, and would be even more likely to move if bots were focusing on the area closest to them. Put simply, your statement-of-fact is based on a false premise - expecting the player to stand still for an entire build to complete is just silly. Additionally, timing the operation from first to last with no regard for the rate of items placed (linear/constant vs. exponential buildup) is equally silly. The game is dynamic, not static.

[mrvn]

I don't need to make a counter argument. My original statement-of-fact is still true and nobody has shown otherwise: closest first is pointless if the player does not move.

Then you didn't read my reply. There are cases where it takes *significantly* longer to complete a blueprint placement without closest first, even with the player remaining still (player runs out of power near completion), and there are also significantly more items placed earlier in the process with closest first. Your statement-of-fact is easily disprovable simply by observing the two types of operations side by side.

Aside from the above, the player *does* move, constantly, and would be even more likely to move if bots were focusing on the area closest to them. Put simply, your statement-of-fact is based on a false premise - expecting the player to stand still for an entire build to complete is just silly. Additionally, timing the operation from first to last with no regard for the rate of items placed (linear/constant vs. exponential buildup) is equally silly. The game is dynamic, not static.

Assumin the player doesn't move then the total distance traveled by all bots is the same no matter what order enities are placed. The amount of recharging needed is directly dependent on the distance traveled and the overall build time is the sum of time to travel the distance + recharge time. So overall the time has to be about the same. I agree with rseding91 that nearest-first doesn't matter for the overall time if the player doesn't move. I think you are wrong there and I would like to see some more argument or proof for your assertion that nearest-first without movement has an overall lower time.


Actually nearest-first might be worse because of the stupidity of bots. A bot will travel towards the destination only to notice half way there that it doesn't have enough power. it then returns to the player, recharges and tries again. Now with nearest-first the bots will do all the nearest jobs first using up a lot of their power. Only then they attempt the further jobs, at which point they run out of power.

On the other hand with the current order they often do the furthest job first and only run out later when they are attempting a shorter flight. The distance wasted to return to the player is then smaller.

Now the exact behavior is pretty chaotic so this might or might not happen. With nearest-first all the bots might ru out of power <5m from the player while with the current code they might run out of power <5m from the destination. But my feeling is that nearest-first for averaged sized blueprint might skew it towards running out of juice on the last and longest flight.

But that would be easy to fix and would on it's own already give a noticeable boost to construction speeds for large blueprints: Before a bot leaves (the player) for the next job it should check if it has enough juice. if not it should recharge even if isn't below 30% (or whatever the limit is) yet. That's a simple "distance / speed * fuel consumtion" calculation and not something overly cpu taxing.


Note: What is definetly wrong is the assumption the player wouldn't move given the huge benefit it gives with nearest-first.

[malventano]

Assumin the player doesn't move then the total distance traveled by all bots is the same no matter what order enities are placed. The amount of recharging needed is directly dependent on the distance traveled and the overall build time is the sum of time to travel the distance + recharge time. So overall the time has to be about the same. I agree with rseding91 that nearest-first doesn't matter for the overall time if the player doesn't move. I think you are wrong there and I would like to see some more argument or proof for your assertion that nearest-first without movement has an overall lower time.

For the case where the player had just enough power to complete an operation, if you save the furthest placements for last, it is more likely that the bots will complete the full blueprint and then sit and wait to charge before stowing in the players roboports. When the placement is random, while the total power needed is the same, more power is used earlier in the process, leading to the roboports draining the player batteries earlier and resulting in a batch of bots stuck waiting to recharge before they can place the last items. This is made even worse by how the bots are queued to place items - you might have to wait for the very last bot to recharge before it places that last item.

But yes, you are right, the player will definitely move. I was just demonstrating that there are cases where it makes a difference even with the player stationary. As is the case with closest first resulting in more items placed earlier in the process.

[Maddhawk]

I would like to see the logic controlling player construction bots, those in a players inventory and using the players personal roboports, changed to build/deconstruct outwards, concentric, from the player.

It is so annoying to watch your bots take off for Antartica to build when there are tons of things right under your feet that could be built.

I understand this is probably to help with the early bot game when the player can build things close around them and the bots can focus on things farther out, but in practice, this just doesn't feel good. It is far better to have a tiny area for the bots to build around the player and the player just moves as construction/deconstruction proceeds. This only gets more so as max out the tech tree and unlock all the improvements. In the mega base stage, it is mostly just running about and using blueprints to design cool looking factories indefinitely and letting bots do all the heavy lifting of actually building everything while the player becomes a pure designer/engineer.

[DaleStan]

Picker Blueprinter adds that feature

[ssilk]

joined with existing thread

See discussion: low chance this will come.

And my own experience with this (changed with mod) was, that it make things differently, but not better, because suddenly you think: why isn’t it building the outer stuff first.

[Maddhawk]

O.o this is an old thread lol. Be so much better though, cause I just scoot my character about to keep things building fast. As it is, I find myself breaking my blueprints down into smaller and smaller chunks and then placing them in tiny bite size pieces for faster building.

[FuryoftheStars]

O.o this is an old thread lol. Be so much better though, cause I just scoot my character about to keep things building fast. As it is, I find myself breaking my blueprints down into smaller and smaller chunks and then placing them in tiny bite size pieces for faster building.

If you're good with mods, there was once a mod that tried to bluff this behavior by dynamically changing the build radius of the personal roboports. I don't remember what it was called, though, and it does add some runtime overhead.

[coderpatsy]

If you're good with mods, there was once a mod that tried to bluff this behavior by dynamically changing the build radius of the personal roboports. I don't remember what it was called, though, and it does add some runtime overhead.

Closest First,Closest First for 1.1, or Closest First With Hot Keys

[FuryoftheStars]

If you're good with mods, there was once a mod that tried to bluff this behavior by dynamically changing the build radius of the personal roboports. I don't remember what it was called, though, and it does add some runtime overhead.

Closest First,Closest First for 1.1, or Closest First With Hot Keys

Thanks, the Closest First for 1.1 was exactly the one I was thinking of. Haven't tried the hotkeys one, yet, though that seems nice to be able to control the range that way.

[malventano]

joined with existing thread

See discussion: low chance this will come.

And my own experience with this (changed with mod) was, that it make things differently, but not better, because suddenly you think: why isn’t it building the outer stuff first.

It was better, and significantly faster, so long as the player walks around as the build occurs. Even standing still, the first set of items is placed faster, and a larger number of items is placed before the first bot recharge cycle. Mod also has >6k downloads so clearly it was useful.

[SANTIMEL]

Goal

Optimization

Situation

Drones waste the player's time and take up computer resources.

Decision

Let the drones build, starting from the closest objects to the hero. Ending with the most distant ones.
ㅤ

Анимация.gif (95.69 MiB) Viewed 810 times

ㅤ
The player, by moving around the area, could speed up the construction of the highest priority objects.
This would reduce the construction time and reduce the load on the video card.
________________

Ps.: People don't take into account the time it takes a drone to fly long distances.
The distance a player can reduce ↴
ㅤ

Анимация 2.gif (81.48 MiB) Viewed 470 times

ㅤ

Анимация 3.gif (13.72 MiB) Viewed 470 times

[computeraddict]

Check out https://factorio.com/blog/post/fff-374

[SANTIMEL]

Check out https://factorio.com/blog/post/fff-374

Please answer briefly, in your own words.
Because the longer the article, the more mistakes the online translator makes.
And as a result, it becomes difficult to understand something.

[PennyJim]

I don't think that FFF even really fixes your problem.

In short, it changes how jobs are dispatched to robots to allow them to have a queue. With the robot who can get there fastest being dispatched, instead of the closest free robot like it is right now.

This does not solve the 'problem' of personal bots not prioritizing nearby ghosts. I would assume it might worsen it as bots tend to get dispatched to orders to the south first.
I also don't really think it's that big of a problem because the solution would be to just get more personal robots. The rendering cost and simulation cost to them is miniscule, and if it actually matters to your computer it might not be suited for Factorio in general.

[SANTIMEL]

…
The rendering cost and simulation cost to them is miniscule, and if it actually matters to your computer it might not be suited for Factorio in general.

For my PC, the high load is not a problem.
But for my nerves, it is a serious problem, waiting for the drones to bother to build what I need.
It's annoying!