[2.0.11] Roboports queue logic 2.0 not working

[Hares]

After all requests are canceled

10-26-2024, 15-36-29.png (2.44 MiB) Viewed 550 times

Few minutes after

10-26-2024, 15-38-01.png (56.82 KiB) Viewed 550 times

Steps to Reproduce

1. Import DocJade's AutoMall and build at least 8 chunks of it
2. Ask it to craft rocket silo, or two

0eNrtHe1y2zbyVVD+aq+ULfBDH57J3bTNNG3v6sukneYyiUcDkZCEmiJYgrSi6/gB+hb34+7F+iS3C5ASbVMfpGVbTdOZNggELhb7hV3sAv3VGkc5T1IRZ6OxlJfW2a/rHmWdva38FX8LuQpSkWRCxtaZ9eOMk7lMOVnKnLAwtEkGPROmMp4SkZEpz9Qn7+J3MQ78Is/k9yyKyELAf2LOQ/NtNmMxoURFIuBETDSsBYszkkkyZ5fQl/G5wmEZmbEr+HsM4Oc8FCzjJEjZJBPxlMCciTrByd7iB89WaHdwXRfkOVdiGsOk4yV5LoPvWMhh9NsrkWY5izr4I4uemT86Ip7IC/L2J54qWCmhJ90T54L8AxZG8iSEecMz4vintHvqdB1vI5hgxgOY+gXPNGEi+BAgXBVQYT1rUp+EMvgZcQrkfCO8GWdpdkHOkXYzHiV/I99JEWvYoVCBTMNPykYVnmVbIpCxYacBhbyM2ZwDE5lSfD6OgIadOQtmIuYd17qGT+KQv7fO6LVd81EqxzKRaVYZ6Fxf2BaPM5EJbqbSf1mO4nw+5ilAsu98bVuJVMJI068WAHH7fs+2ljDY83sAG9DOUhmNxhxYL2SKw1LOwpEWitFchhxntqHzlxyIO5qICKRD4TjFA4RscFmt5uIaF3QLNWeFGtIpA+nrAN3GImYZzFmHpXfil3gOTvwNmK4x2ICNba3wvdGbLRNEppACa4VdIQcvoecX+AGWAJ2xTOd6EKCcsFSjfGY90x05qi0uGpdtJRFb8nR0U4m/kQvQs3hJMjHnCrVOJQCZMKNb5Gc5PkENFvElkRMQNqEIU2aQ1jyjn3mCiinJBtF9eUGCWR5foop+DQjnETsjnxaqLc1Un5HTLZ8/WxkCTgqZBSujjUnKFU/BMkxSOde/gyzkqN5fkCsGKoZ4UxyVR5kCNEks1/jDsFcsnvIzQj+3amTDbSwb/lPKxptmsuF0twrHayY0jzMJxGZxwMHE52lspABZru11SsYSCBvCMo2J5rHMpzMtUcjdkEfiSm8JwEBto79kihPFCwFShHZPyMuIY++3cZDyOTABtgS5iJbk01AaMdM7S7F9SDCeYAguCUguIIMoznDOk89sg5yIkzxD0CBqmUgiMJlof1O0/37XYIX7CNg7MlurQHCp5XEB6yZjPsENKsB1o30sVeKkTky8FSPAAiMtOwmLebTLeAy1gIQiNSJgnQ2Aw/x9pndXBvpCAAeSK7PC9S4K2+q3Zq/UBEfkhVJgAm2SGDpGsOsA+S9juYDBsyxL1Nnpac32cIoM6eCmWGwUiOgOKdM7kVVnSv3G6tJ7SnV51dCU+lvV5atIBpfkhwQ26BPyqdNxujaZiekMZV8VjpFNxiCYFWOkvSBjawMZRQKdAzCxceEfodKAYdS6tEAIn72LvwGYJNCTKZxMoZDCvznwHSQpEWALwZ+65OBbTG2ymIlgBj+EecCNAZWgjuiL8ckE3K44WBrTDjq5hBnmoKNvQLTmbGnECzSChT/nyvgxi9tGAc2AUTpcEKgvyF9YqyW9Ff3RgcvnHR4BM1MRdBIAVise/ZviUQO03xho75YG1gAdNAbap7eAgj+0AMVGiXxLbcf2befC1q2ebjnQcnXLXf0Kv9j9ouVDy4dW36b2wKa65UDL0S0fWv4FzIECAmiu/XTbitgYTM+ZZVzhOg/vgtzwyTvkG/Cq4MvCOQU97jlDbzj0Peo5DqVrP6+LxPoYFHwAQYGKWdLJZGeairCQYmokuH/dNGRwNocMOywwMqaDxnaO+3G7gCLkgQh5unWnoXpl3dv7rVe/3xQQR/BbKFY7T/VvgM9EpBBy7L1SDrSyrm9tLn+17BtwRjHPFjK9VCbUAcZMWKS4bU1TzgHfLM25Ni0yz8DDuc2hvVDYsoMpFsMC/82N/2QTGaO9X1pbgyalbaPcTn+3Ef1lAltLgRPsMaEWWNMYGW0baZW/wmXTTat5CXug1gTzpbYa2338fSTJf3pJAnNh3N478vTsceXpFiLJcqQ9pRGGYiMtQ6sJ7yCCU6/w0IO2SSaLQA4VMWiinUQ3N0MBtclEvAfHJoWZQxNQoCe8w0vfg9H9J2e03ixqeNyaYQmE8btYhUzY6tmzVGQzMNfgDG0j37AR+dZAb1GwpZWFKAHAjMooBBCxb1iVz62ShE1hbxTRf4KxxBASA956m9lrSkNKP1Ai7rJSdcZhu/O/vxNAn1Cjz432lfSkh1Ptqi3eYkfP9YlCzBdmi7e2xj7709T5IGlasb/b7eUGYpe7FdGAIBDnMTmvI/mwqWFwG0nyn8K40m47IjqPTMTzWgp26E0S/qUFCc+30O+cTzE2rpU+SptSzj8G8Wv8XZW+p4cX0a/BsG6WTqcdjZ1jUXHahX/uL6M7aPi9Oa5f6l2KBUGeMjydLA80rvTxaC193ab07T+JDK+2lAexAAX0jeQNU5loUpZo3KVjmxjJOY4Y6RG8qjqKtYyMHlvyytjvQQTPAN9sGnVyhhTLIwXYOmL22hHzjgSivX1Iar6uN5I3KdlpQcnXVn2kQ/stg8c/yi5dyudhdphb87ePMOmgMd2dMhN0/WR79f3J+K8t6vwaAxkRK55iypWwlBO1ABup040sDDFPU6YKdeoyxZ4kBWsa6w48pgOEcGOPWDrVaUuRCK5q04Z02FL0j8Z5OoSJ3RUgmVhT58QWXPMEBV5TWrtPqkybKUlkhknpomxDl1MAommGybWi1KD2oNxpHGIZPrgf49QKEWmzGonSmriPXh2BdrJhqZm9Au/sBG9sb7N6pcoE7s4JMJXaDL5bge/thL/kUSQXzWbwKjP49l57YiP4fgV+byf8YMkacqBXgd/fCX8xA5PTbIJ+ZYLBPjK0bAZ/UIE/3EOEWNCQA8PKBLgR70qAxxPZUMu61Rl2q3G3IfiqFtPdakwbgq/qMN2txE5D8FUVprt12G0Ivqq/dLcCe40LzCrgd+uv3xB8VXvpbvXtNQRf1V26W3n7DcFXVZfu1t1BQ/BVxXV2K+7woKW2PxYFdOg2vzp/QTI2jnitN+w4LfIz3r7x8ZMkaNrULNiN0dB7RYvA9NWdDPzvv/3XapHBLKHwUTEji8P2R1Pn90hM4akWAd+FBDNdwamPucgEq7AwUsPiYayqz4qTGpDKFMurbUJPnW4xGmQfwz9iyIlVdj9ht5jj3Y5qsZ7KTUlftirGXlfwF2XjJvpgpiZOaSwgajwxdYKgFRGEjJmuch1jNY9QPDTl/qbIFktqxxhupjEPbSwJxCimbrapLiaXk8mdyTR0U5eLZbkMcFdKXGG/CliobxHoiwWhCaNqVdNtWjZa8e3r4HntUlreY5+GPWTAZdR2c2FQGCrilCVe+sKHqZrXlaSmO4auBawUBFupIgoGHlcIWUd8v13G5mOwWyVirx0RvSNOez1A6vBLrNQnY4g1zDUqRow/gfI75bWE7bfLd7l/kNPgl4dL2LbaqXecHtd5JJuY+1xcgUtldpvy2lktSwftWOp9mCnMOgoNG7m+w0YS/0EmJ91uQ4+Edre7JC5twYInjT7uWzXSsF7/UNakrVCEPNZRzr711nU8rtT2wyYUdSI2T+qSLDtPpgORBrnIRjzGcHaFRNm9YmzbBOxmtfr9t//hgFxxmCWSePRt5k6n41GLemkAUblvbqrRR7LkVg0N3ZY5K+84Mtne/S356y0Oj464VILpwPK6lk3eezp7qMr0oY5rQ7mITQ6x9upGJUKqu5Z0l8ruHumUbKTzkXwlM/jmgOkaTUQs1Gwty+Y9ghj0KhRcv5pR6S8ycOu+GyD2J+Vz5FEBrCkD7tLMb3Z1x8ilv69cNrq743S3Xd4x92DxOMxc5Ee5SJe60xxPoJQUzDbVtSKMat1lt9fi0Kz3hJ7D2vJUk/r334tanJu92GVp/3O4wzD7vmVNe3/35jB7ewuMX7cMSQ5LryMQrOeHuQ55KMqUntMTOXwHV8xn1iPLzLGcbuuyI9wkFNfXx4viIkyvwD4iwncx/XuZa8ENw7gX7+Kv9blhuTvX3Bu/eW3eJmHNBfLa3aff7hzXf+TI/k2tK+gfoJrszT413+bRFnz3JcZz2iRlc/1mC2z7U47XaMCbxzjCeAO1hG52d8l98m1+HWRuC2Qexxyb76/3tCJtFfvFPRT7hZThSps3FxG7w3aHzv7RpE0OcZD2fIvKfYWk1yZSxFc8zdZvIJnkyILr9zZq71B32xG399jEff5QSZHnG04nPdri6oT/hMbnxUPk5Q/zlsA9Tq88pwUbeh8aGw7h5Ll3nbwjYK/b7oaI/wGlZXXN4Gbrjs5SUfwgwH1Cp1a/gmLOtOpo6rWjae8Pkkw09Drc1ZIWIWqb2ygb2Dsv/WXDVP3yKUYg5V+BHSFhc112Vsdsv9lRWMPjv4ewkOUrjwd6PmmzbZxEuQjX0y9Y8SbV/Q1y01D8FiYq42x+FJgEaR7yjhTRUWCTcBRAns87U6aOAqNITGfZ0dBnxtnV8miwifJxKgITWByBTuXRJMdMOAOL9ZAYtfWZqmbvns9nfaUfINHHW0gEhU+7wQ6SMKXf1Cp8AzwsE5kyKbmNBcjeOpcyzqPLTnkRcMtNSL/mndtt+WKdPJsx4zdl1bRaOUL/qIeZrCyt9RXb3pnt/Xlq+Ion/gg+D3JGdLUtCJMkaiYXiixm7GaWDY9N06V5/9XIia3PESoHCProYP2ud60Irc/pCgcGvZAZ/LlFiHo7ywxQFEZyMqqQjNZUGzxEOcJ+0VOjp+ptK0uZmo1iiQphqFRJOxdg8PhsnE8mvCxxqFWE4d4q61ZUtu4ZuMrxD2B9xTtJKq+MF7mBf26Ff3UQacuiaSxVqgXotK15MhBvPtxLbcfVr+9iE3hKi0d8Hbd4zxf+dIper3i8F5/2Hdqebnk2eMpO0XR83QsAbbA0bvH2r9MremHAUI+Fhk29ogmj+3oCH3vNQ8G62def+TjA18B8nM1M0cMpPN3bW0OoviDs2cNVi3Z1c4DIOPr7Aa7LrHZoBmAvRSLAehAs1c8XG7jUXSMMbbecGrtwTZ5pe4iHHoNIQyBCTRt+KfoRba+Aj48h04H5FtuuW7ZdHKO/7a/pAH/AzL2yH8YMyjYgY3hAcYWeeX+ZDnEuQzhouyvm4no9QyWggItMw34Hue4a8iPHbces0dEPORsWOprJhRC4a4HRbRD0ou1gv7Nq03XbX7V9HOOXbejXbQ9hGpwdpBXMVbRdpLOGjzRxCxwGhv5FezUG0bJ9p2w72HZM28c2zuXSNX1cuqatq3E2vHYRH8/ggF221y37oe1V2oZuCAJxc1ftQdkGmEZOoGs972DNa2gDXwx9TLvAucJHV/POyKqHa/SMlnnIR8/Q33PX4z2UVcBT93trviOrSvr4dE0fZIOhz8Fe3v6BT/F/d7DX49t6U7g9rX7MujL3CrZ+ohp++PhA95/h/9rzUE9wm11+VD7/vkVMr/8PaDVx7A==

Copy blueprint

[kovarex]

Hello, you should describe what do you actually consider to be a bug here.

[Hares]

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.

[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

[Hares]

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.

[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"?

[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.

[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 251 times

[GenosHK]

I came here looking for answers as well.

11-07-2024, 15-22-05.png (1.37 MiB) Viewed 232 times

11-07-2024, 15-22-26.png (103.91 KiB) Viewed 232 times

[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 182 times

[mrvn]

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).

[GenosHK]

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.

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.

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.

[mrvn]

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.

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.

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 100 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 100 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.