[2.0.28] Robots from inventory work sequentially

[T3rm1]

https://youtu.be/31e2wUrbomU

The video shows three to four robots working on the last few tasks. It could be more. Often, it's even worse and only one robot is doing one task after another. I have not recorded that but it should be easily reproducible.

[Muche]

With enabled show-robot-tasks F4 debug option, it seems that the initial task assignment is one upgrade task per robot.
Then the robots who finish their upgrade task first get assigned from the rest of tasks up to their maximum.

Robots-UpgradeTaskScheduling.jpg (128.41 KiB) Viewed 570 times

[T3rm1]

I had 20 robots available. The video shows that it doesn't work. If required I can try to record another video where only one or two robots do the tasks one after another.

[Loewchen]

Post a save that lets you reproduce the issue, see 3638.

[T3rm1]

Here is another video showing the problem. It's really easy to reproduce. Also attached the save file right before the bug. You just need to apply the upgrade plan.
https://youtu.be/BRcvIL1zbm4

[T3rm1]

Post a save that lets you reproduce the issue, see 3638.

Anything else you need or can this be moved back to bug reports?

[vark111]

I've had this bug appear numerous times in my game as well. It seems to happen any time you upgrade (or delete) more items than you have bots. If I have 10 bots and I upgrade 20 items, the first 10 items get upgraded all at once - one item per bot. After that its a crap shoot. The worst case scenario though, is when all the remaining 10 items all get upgraded by a single bot while the other 9 bots sit in your inventory doing nothing.

I've only had the worst case scenario happen once or twice. What usually happens after that first 10 in parallel, then 5 or so bots do a parallel upgrade of 5 items, then 2 bots finish the job running back and forth.

Considering the bot behaviour changes described in FFF 374 I doubt this problem will 100% go away since the bots are dynamically allocating jobs based on travel time, but it seems the most egregious examples of a single bot flying back and forth 10 times while the other 9 bots idle seems like something to at least be looked into.

[robot256]

From the description it sounds like the travel time is being calculated incorrectly for certain jobs, or when adding certain jobs at certain points in a robot's queue.

I think this deserves some attention. Maybe the logic update can fix jobs getting stuck when bots take longer than expected at the same time.

[T3rm1]

This is from the FFF you linked. It's possible that this can cause the behaviour observed.

The first change was to allow robots to have multiple tasks assigned to them. Much of the code has been written with the assumption that a robot has exactly one job, but after some code refactor, robots now have a queue of tasks.

It appears that the remaining tasks are not correctly distributed over all robots but only a few. In my save game there is no logistics network, only personal robots. Shouldn't the moment I use the upgrade planner all tasks be assigned evenly to all robots?

[robot256]

My hypothesis is that the code calculating when a bot will complete its existing task queue does not properly iterate over the list of upgrade jobs, and only returns the duration of the first upgrade job in the queue.

The jobs are assigned to bots one after another. When you have 10 bots in your inventory, they start at the same position, all with empty queues. The first ten jobs are all assigned to a separate bot because among bots in the same location, it always prefers a bot with 0 jobs.

When the game tries to assign the 11th job, it sees 10 bots at the same location but each has a different job. It has to decide which bot will complete its first job the quickest and assigns the 11th job to it.

When the game tries to assign the 12th job, the game sees 9 bots with 1 job and 1 bot with 2 jobs. The queue time calculation is the same s last time for the first 9 bots, but the last bot has 2 jobs so the queue time should sum the time for both jobs. BUT if the algorithm only looks at the first job in the queue, then the same bot will "win" every time no matter how many jobs are assigned to it.