Page 1 of 3
[Genhis][2.0.11] Roboports queue logic 2.0 not working
Posted: Sat Oct 26, 2024 12:40 pm
by Hares
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Sat Oct 26, 2024 12:55 pm
by kovarex
Hello, you should describe what do you actually consider to be a bug here.
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Sat Oct 26, 2024 1:06 pm
by Hares
kovarex wrote: ↑Sat Oct 26, 2024 12:55 pm
Hello, you should describe what do you actually consider to be a bug here.
In
FFF-374: Smarter robots it was said that robots should now take into account how many other robots are recharging and want to recharge on the specified roboport:
Surprisingly in this case the issue can be helped a lot by just a small improvement in the heuristic logic. When deciding which roboport to charge at, the robots crucially did not consider the current robots on the way to that roboport, only those already in the queue, and did not factor in how many free charging spots the roboport has open. By adding these two extra parameters into the equations, the distribution of the robots improves quite nicely.
However, what I see is here is the old behaviour of many "vacant" roboports nearby and one collecting a queue of millions of robots to charge.
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Sat Nov 02, 2024 6:51 pm
by Tem3dy
Agreed, I've had the same problem happening despite having multiple roboports available, I feel like the new behavior isn't very improved, or at least there are some issues with it.
Sometimes the task assigning works unpredictably as well, for example when I was placing down rails (both in range of personal roboport and a roboport network), the bots from my personal roboport were waiting for trees (obstacles) to be deconstructed, and that task was assigned to bots from the other end of the base, meanwhile I had 50 robots available in my personal roboports that didn't take the job
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Sat Nov 02, 2024 7:55 pm
by Hares
Tem3dy wrote: ↑Sat Nov 02, 2024 6:51 pm
Sometimes the task assigning works unpredictably as well, for example when I was placing down rails (both in range of personal roboport and a roboport network), the bots from my personal roboport were waiting for trees (obstacles) to be deconstructed, and that task was assigned to bots from the other end of the base, meanwhile I had 50 robots available in my personal roboports that didn't take the job
Observed such behaviour too.
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Wed Nov 06, 2024 4:36 pm
by AndrolGenhald
I've seen this a lot as well, my guess is that it's due to the last change in the FFF, that robots must always charge at a roboport closer to their destination than they are. Perhaps this needs to be relaxed a bit somehow? Maybe rather than having a selection criteria of "closer to destination" it should be "closer to destination OR within single charge flying distance of destination" or maybe some heuristic like "closer to destination OR within single charge flying distance / 2 of current position"?
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Wed Nov 06, 2024 5:40 pm
by mrvn
That "closer to destination" logic, neigh the whole recharge logic needs to be redesigned.
When the bot leaves a roboport (or takes on a new job) it should check how far it can go before running out of fuel. If that is before the destination then it should look for the best roboport to refuel from there and then set course directly there without going zig-zag all the time.
And since the bot is at a roboport (unless it gets retasked mid flight where you just skip the closer test) the choice of the next roboport to refuel can ignore that roboport and any further away from the goal while still picking a roboport that isn't overcrowded. It also means the bot can travel half it's charge and recharge at some closer roboport instead of trying to go all the way and then ending up at an overcrowded roboport because any other roboport would be out of range of the remaining charge. Planing ahead where to refuel gives a lot more options.
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Thu Nov 07, 2024 1:49 pm
by Skyl3lazer
This occurs for me as well in 2.0.14. Whatever roboport is closest to the center of traffic will end up with a queue of hundreds of robots, rather than spreading around to other chargers.
- 11-07-2024, 08-49-30.png (126.28 KiB) Viewed 1422 times
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Thu Nov 07, 2024 9:22 pm
by GenosHK
I came here looking for answers as well.
- 11-07-2024, 15-22-05.png (1.37 MiB) Viewed 1403 times
- 11-07-2024, 15-22-26.png (103.91 KiB) Viewed 1403 times
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Sat Nov 09, 2024 1:45 pm
by Xellnix
same at my end, while they have options (black circles) to recharge, they stack at these 2 roboports
(i use basice logistic bots with +825% speed +3 capacity, also basic roboports)
so even if they would move slowly to the circled ports they would be faster than stacking and waiting for recharge
but, not all stack there, some move away, so i would guess like the others suggest, something to do with destination?
- roboports.png (719.7 KiB) Viewed 1353 times
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 11, 2024 7:25 am
by mrvn
GenosHK wrote: ↑Thu Nov 07, 2024 9:22 pm
I came here looking for answers as well.11-07-2024, 15-22-05.png11-07-2024, 15-22-26.png
First I wonder why you have big miners going into requester quests, seems kind of backwards.
Second the bots do split between the two closest roboports. If they just delivered the items requested by all those requester chests and are looking for a place to rest that might be different to the normal recharging logic. Is this a case of bots looking for a resting place?
The other roboports seem to be far away so the distribution logic might not trigger there. But bots should compare the total time (travel + wait in queue) for every roboport as far out until travel time exceeds the best roboport found so far (as in I think they should, not that they already do).
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 11, 2024 2:10 pm
by GenosHK
mrvn wrote: ↑Mon Nov 11, 2024 7:25 am
First I wonder why you have big miners going into requester quests, seems kind of backwards.
I set the chests to automatically trash non requested items, so the bots come and take the scrap to storage automatically. I've since swapped to training it all out since the robot charging shenanigans were ruining this method.
mrvn wrote: ↑Mon Nov 11, 2024 7:25 am
Second the bots do split between the two closest roboports. If they just delivered the items requested by all those requester chests and are looking for a place to rest that might be different to the normal recharging logic. Is this a case of bots looking for a resting place?
They do split between the two roboports, but they will eventually stack up to ONLY those two roboports to charge. Over 7000 robots trying to charge at two roboports instead of spreading out to the other roboports just across the gap seems like the queue logic isn't working.
mrvn wrote: ↑Mon Nov 11, 2024 7:25 am
The other roboports seem to be far away so the distribution logic might not trigger there. But bots should compare the total time (travel + wait in queue) for every roboport as far out until travel time exceeds the best roboport found so far (as in I think they should, not that they already do).
They obviously aren't that far away since they are in the same network. It's slightly more than what large power poles can span. I agree that they made it seem like total wait time should be the determining factor, but I assume it has something to do with wanting to be moving toward their goal. A lot of these charging aren't holding an item making it seem like they are trying to be nearby to their destination, but when 1000 robots are waiting to charge, you'd think it'd be able to tell that it's not the best solution to become number 1001 waiting in line with 30 alternate roboports that close.
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 11, 2024 3:47 pm
by mrvn
GenosHK wrote: ↑Mon Nov 11, 2024 2:10 pm
mrvn wrote: ↑Mon Nov 11, 2024 7:25 am
First I wonder why you have big miners going into requester quests, seems kind of backwards.
I set the chests to automatically trash non requested items, so the bots come and take the scrap to storage automatically. I've since swapped to training it all out since the robot charging shenanigans were ruining this method.
Ah, so those requester quests are actually all active provider chests. The big drawback of this method is that the ore will fill every storage chest you have and then deadlock all your bots before the miners will stop mining. I can't see that ever being useful. Just use provider chests and let the bots fetch ores you request somewhere else.
GenosHK wrote: ↑Mon Nov 11, 2024 2:10 pm
mrvn wrote: ↑Mon Nov 11, 2024 7:25 am
Second the bots do split between the two closest roboports. If they just delivered the items requested by all those requester chests and are looking for a place to rest that might be different to the normal recharging logic. Is this a case of bots looking for a resting place?
They do split between the two roboports, but they will eventually stack up to ONLY those two roboports to charge. Over 7000 robots trying to charge at two roboports instead of spreading out to the other roboports just across the gap seems like the queue logic isn't working.
mrvn wrote: ↑Mon Nov 11, 2024 7:25 am
The other roboports seem to be far away so the distribution logic might not trigger there. But bots should compare the total time (travel + wait in queue) for every roboport as far out until travel time exceeds the best roboport found so far (as in I think they should, not that they already do).
They obviously aren't that far away since they are in the same network. It's slightly more than what large power poles can span. I agree that they made it seem like total wait time should be the determining factor, but I assume it has something to do with wanting to be moving toward their goal. A lot of these charging aren't holding an item making it seem like they are trying to be nearby to their destination, but when 1000 robots are waiting to charge, you'd think it'd be able to tell that it's not the best solution to become number 1001 waiting in line with 30 alternate roboports that close.
Indeed, a whole lot of bots without ore in hand. So they went to recharge on the way toward the chests. And close to the target as well. So the code that is supposed to prevent bots from not making progress might really be interfering with splitting the bots to more roboports. Be aware that when the bots decide to refuel is when they are nearly out of fuel. The distance they can still travel fast is very limited. They would have to slow crawl to any but those two roboports. Quite likely the distance is simply to far even without a "must be nearer" logic going wrong. But only the devs would know the real internal logic there.
The current method looks something like this (purely from watching gameplay):
- current-refueling.png (720.6 KiB) Viewed 1271 times
The path of the bot is drawn in black. The green/red background signifies the cost of refueling. The further away the bot has to go the longer it will take. As you can see most roboports are fully red and the bot would never go there.
As I said before the decision to refuel should be taken where the bot leaves and not when it runs out of fuel. First the bot just looks at the direct path (grey). If it can't reach it's goal it looks for a roboport to refuel at. This is the same spot as before, just now the bot searches for a roboport before it leaves instead of later when it actually runs out of fuel. And since the bot hasn't actually left yet the cost of picking a roboport differs a lot. It could pick any roboport within a circle where the grey line is a radiant. But anything not along the grey line means the overall distance is longer so cost rises. And you want to recharge as late as possible to minimise the number of stops. So a very rough sketch of the cost function done in a minute in gimp is something like this:
- plan-ahead-refueling.png (1.09 MiB) Viewed 1271 times
As you can see the cost function is no longer a circle but more spread out along the path and fewer roboports are fully red. Actually none but the starting roboport (and anything to the left of it) should be disallowed.
On top of that add the wait time for each roboport from the (number of bots registered to stop there) and pick the cheapest. Instant balancing of bots and no wasted zig-zaging of bots.
Re: [Genhis][2.0.11] Roboports queue logic 2.0 not working
Posted: Sun Nov 17, 2024 11:01 pm
by Trollseidon
- 11-17-2024, 14-56-13.png (4.88 MiB) Viewed 1106 times
[2.0.15] That's roughly 2000-3000 construction bots all deciding on the same exact roboport is the only place they want to get a recharge from. All arrived relatively slowly one after the other but all following the same deconstruction order of a few boxes filled with stuff.. This entire city block is surrounded by roboports, not just the top corner. It works most of the time but there has got to be some bug somewhere that just makes it so all bots only want to charge from a single roboport nearby and ignore the others.
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 18, 2024 12:51 am
by Hares
mrvn wrote: ↑Mon Nov 11, 2024 3:47 pm
As I said before the decision to refuel should be taken where the bot leaves and not when it runs out of fuel. First the bot just looks at the direct path (grey). If it can't reach it's goal it looks for a roboport to refuel at. This is the same spot as before, just now the bot searches for a roboport before it leaves instead of later when it actually runs out of fuel. And since the bot hasn't actually left yet the cost of picking a roboport differs a lot. It could pick any roboport within a circle where the grey line is a radiant. But anything not along the grey line means the overall distance is longer so cost rises. And you want to recharge as late as possible to minimise the number of stops. So a very rough sketch of the cost function done in a minute in gimp is something like this:
As you can see the cost function is no longer a circle but more spread out along the path and fewer roboports are fully red. Actually none but the starting roboport (and anything to the left of it) should be disallowed.
On top of that add the wait time for each roboport from the (number of bots registered to stop there) and pick the cheapest. Instant balancing of bots and no wasted zig-zaging of bots.
I would propose another solution to the problem -- add the final destination to the list of valid roboports to recharge at. As absurd as it sounds, this might solve all the problems while maintaining most of the current implementation. So, the idea is -- estimate flight time to the destination (respecting the low-charge mode) and set it as a limit on recharge roboport tributors. So, for example, it is required 15s to finish the task, all roboports with flight time + queue time >= 15s should be ignored. Consider this as a super-extreme conditions of "select roboport that will bring you closer to the objective" directive.
Re: [Genhis][2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 18, 2024 10:08 am
by lelick
Might be related to the other problem I observed
viewtopic.php?t=118435
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 18, 2024 11:06 am
by mrvn
Hares wrote: ↑Mon Nov 18, 2024 12:51 am
mrvn wrote: ↑Mon Nov 11, 2024 3:47 pm
As I said before the decision to refuel should be taken where the bot leaves and not when it runs out of fuel. First the bot just looks at the direct path (grey). If it can't reach it's goal it looks for a roboport to refuel at. This is the same spot as before, just now the bot searches for a roboport before it leaves instead of later when it actually runs out of fuel. And since the bot hasn't actually left yet the cost of picking a roboport differs a lot. It could pick any roboport within a circle where the grey line is a radiant. But anything not along the grey line means the overall distance is longer so cost rises. And you want to recharge as late as possible to minimise the number of stops. So a very rough sketch of the cost function done in a minute in gimp is something like this:
As you can see the cost function is no longer a circle but more spread out along the path and fewer roboports are fully red. Actually none but the starting roboport (and anything to the left of it) should be disallowed.
On top of that add the wait time for each roboport from the (number of bots registered to stop there) and pick the cheapest. Instant balancing of bots and no wasted zig-zaging of bots.
I would propose another solution to the problem -- add the final destination to the list of valid roboports to recharge at. As absurd as it sounds, this might solve all the problems while maintaining most of the current implementation. So, the idea is -- estimate flight time to the destination (respecting the low-charge mode) and set it as a limit on recharge roboport tributors. So, for example, it is required 15s to finish the task, all roboports with flight time + queue time >= 15s should be ignored. Consider this as a super-extreme conditions of "select roboport that will bring you closer to the objective" directive.
That would make it much much worse. When the charge runs out near the goal then only the one roboport next to the goal will be allowed for recharging and all 10000000000 bots chopping down trees will queue up there because they all want to drop of the wood in the same storage chest (due to the wood filter on the chest).
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 18, 2024 11:11 am
by Hares
mrvn wrote: ↑Mon Nov 18, 2024 11:06 am
That would make it much much worse. When the charge runs out near the goal then only the one roboport next to the goal will be allowed for recharging and all 10000000000 bots chopping down trees will queue up there because they all want to drop of the wood in the same storage chest (due to the wood filter on the chest).
Nonono, what you described is how it's working now, I suggest just completing the job instead of charging when all eligible roboports are too full.
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 18, 2024 11:31 am
by mrvn
Hares wrote: ↑Mon Nov 18, 2024 11:11 am
mrvn wrote: ↑Mon Nov 18, 2024 11:06 am
That would make it much much worse. When the charge runs out near the goal then only the one roboport next to the goal will be allowed for recharging and all 10000000000 bots chopping down trees will queue up there because they all want to drop of the wood in the same storage chest (due to the wood filter on the chest).
Nonono, what you described is how it's working now, I suggest just completing the job instead of charging when all eligible roboports are too full.
Well, yeah. I always get annoyed when the bot turns around 1 tile before the goal to recharge too. They should just finish the job as that's worlds quicker than going the long way to recharge.
But I think you see only this as problem as that is where you usually watch. The bots will clump up on roboports mid flight too when you place large blueprints. Especially when you have a central mall that produces everything. All the bots will go to the mall and then travel near identical paths. So they all run out of charge at the same spot and then use the same roboport to recharge.
Mid flight your suggestion doesn't help because the time to target will be huge and the current algorithm then picks bad roboports to recharge (clumps up) or going to a more distance roboport takes forever.
My suggestion makes it so a more out of the way roboport is chosen but preferably one that is reachable with the current charge. By not going zig-zag flight time is significantly reduced for the recharge when considering the same roboport.
Re: [2.0.11] Roboports queue logic 2.0 not working
Posted: Mon Nov 18, 2024 11:41 am
by Hares
mrvn wrote: ↑Mon Nov 18, 2024 11:31 am
But I think you see only this as problem as that is where you usually watch. The bots will clump up on roboports mid flight too when you place large blueprints. Especially when you have a central mall that produces everything. All the bots will go to the mall and then travel near identical paths. So they all run out of charge at the same spot and then use the same roboport to recharge.
With 2.0, they clump up only at the end of travel, because there's only one roboport that will bring them closer to their destination -- that doesn't happen mid-flight. I've experience enough with the first revisions of DocJade's AutoMall, and even if there were only a single roboport in the middle of the base (which there were) and robots were to travel accross it (which they were), the queue time near it was insignificant compared to the queue times near the either end of the route (since they have to pick up item first on one end of the base, and then bring that item to the other end of the base).