Personal robots prioritizing nearest first

Ideas, that are too old (too much things changed) or won't be implemented cause of some reasons or if there are obvious better suggestions.

Moderator: ickputzdirwech

Rseding91
Factorio Staff
Factorio Staff
Posts: 11877
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Personal robots prioritizing nearest first

Post by Rseding91 »

It's not going to happen.
If you want to get ahold of me I'm almost always on Discord.

malventano
Filter Inserter
Filter Inserter
Posts: 330
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Personal robots prioritizing nearest first

Post by malventano »

Rseding91 wrote:
Tue Sep 01, 2020 3:50 pm
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...
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.

Rseding91
Factorio Staff
Factorio Staff
Posts: 11877
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Personal robots prioritizing nearest first

Post by 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.
If you want to get ahold of me I'm almost always on Discord.

mrvn
Smart Inserter
Smart Inserter
Posts: 4284
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Personal robots prioritizing nearest first

Post by mrvn »

Rseding91 wrote:
Tue Sep 01, 2020 8:15 pm
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
Filter Inserter
Filter Inserter
Posts: 330
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Personal robots prioritizing nearest first

Post by malventano »

Rseding91 wrote:
Tue Sep 01, 2020 8:15 pm
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.
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.

mrvn
Smart Inserter
Smart Inserter
Posts: 4284
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Personal robots prioritizing nearest first

Post by mrvn »

malventano wrote:
Wed Sep 02, 2020 4:22 am
Rseding91 wrote:
Tue Sep 01, 2020 8:15 pm
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
Filter Inserter
Filter Inserter
Posts: 330
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Personal robots prioritizing nearest first

Post by malventano »

mrvn wrote:
Wed Sep 02, 2020 1:45 pm
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.
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.

Post Reply

Return to “Outdated/Not implemented”