Idle Bots

[connorfarrell7]

I have 40,000+ construction bots in my factory, and I have placed thousands of ghosts on the map, but when I hover over top of a Roboport, it shows that only ~1000 bots are actually working. Some of the Blueprint's I have Stamped down have been sitting there for 10+ minutes untouched. If I go close enough to the ghosts I placed then the robots from my inventory will fill them in, but the vast majority of bots in my factory are sitting idle inside various Roboports. I have Full Storage chests waiting to be used, that are in the same Logistic Network.

Anyone had this problem before??
Or any ideas as to what is going on??

[5thHorseman]

You can't assign tens of thousands of jobs and expect the game to keep up. Let your poor bots finish a blueprint before you slap down another. Or another dozen.

[astroshak]

The game only assigns so many bots to jobs per tick.

The game ALSO counts flying bots that are sitting there at a port waiting for a recharge as busy.

Something tells me you have 600 bots (the number of jobs the game assigns per tick) working, and another 400-odd waiting for a recharge. Or just busy flying around, it sounds as though you have a huge logistics and construction network?

[Guenni7]

When I enlarge my solar fields I can get something around 2000 construction-bots working, but if the construction-area gets too big this number decreases.

[Silari]

There's already a thread on this just a couple posts down: viewtopic.php?f=18&t=93874

The game only assigns 3 jobs per tick per force per surface. If a job fails due to not having materials, it stops checking for that tick. Alerts last 10 seconds, 60 alerts per second from failures gives the 600 alerts that show up when the queue is too full. Mods can change those numbers. There's no limit to how many bots can be active at once beyond how many you have.

Players have their own separate handling, which is your personal bots start building when you get into range. The same thing happens with a Spidertron if the player enters it.

The game ALSO counts flying bots that are sitting there at a port waiting for a recharge as busy.

Charging doesn't effect whether a bot is considered in-use. If it's heading back to a roboport to dock, it's idle, regardless of whether or not it needs to recharge.

[astroshak]

I made that statement based on my own experience.

I had a game once where I went big into bots for outposts. A train would deliver 50 construction and 50 logistic bots to a station at each outpost, and the bots would then be inserted into a roboport based on the total construction bots, or available logistics bots. When the chests got low, the train would come to deliver more.

I had an outpost with some 60k to 70k logistics bots. 95+ percent of them were charging, or trying to. And the roboport statistics said that they were all in use.

Were they all in the middle of a delivery? I don’t know. It stands to reason that some would have been, but that a roughly equal number were done with their delivery and were headed back in after charging. There were too many to really tell what they were doing. And yes, I had WAY too many bots for the number of ports I’d set up.

[Silari]

Bots that are out can be assigned a new job without returning, at which point they're no longer considered idle. I confirmed in-game from the idle stats in the roboport tooltip. So even if they had finished a delivery they likely would've been assigned a new task already.

[blazespinnaker]

Not sure if this is your issue, but I think there is some bugged behavior occurring when blueprints are out of roboport range.

For example, try printing something very large outside robotport range and the robots will grind to a halt. Or at least they did for me in 1.1.6 or so.

You'll also see some performance issues when there are many robots flying concurrently, but that doesn't sound like your problem. I think I saw it around 10K or so.

Also, make sure the blueprints are actually in the same network as your bots. It's easy to accidentally not connect roboports. Just mouse over the nearest roboport and it will say.

[Zavian]

Not sure if this is your issue, but I think there is some bugged behavior occurring when blueprints are out of roboport range.

For example, try printing something very large outside robotport range and the robots will grind to a halt. Or at least they did for me in 1.1.6 or so.

That is not a bug. In my opinion it is the expected behaviour of the queue implementation. (You can argue that it is undesirable behaviour, but every alternative I can think of is just as bad).

Consider what happens when you place a large blueprint (eg a large solar field) with say 12000 ghosts, and 11000 of those ghosts are outside of the current roboport construction range. The game will spend 200 seconds looping through the 12000 ghosts, and only manage to dispatch bots to the 1000 ghosts that are in the current roboport range. It will continue to loop through the queue, unable to find a ghost that can be built until the bots place some of the roboports and expand the construction range. At which point maybe another 1000 ghosts can get built.

If you want to speed things up, then you should either build the roboports (and their power supply) before placing the large blueprint, or build the roboports (and their power) with your personal bots. If all of the blueprint area is already covered by roboport construction range (and assuming you have enough bots and items), then the game can dispatch bots to all 12000 ghosts in 200 seconds.

[rain9441]

I have a suggestion to increase the processing rate for the construciton bot queue here (viewtopic.php?f=6&t=94208). I wasn't thinking it was a bug so I created a feature request to change the rate at which it processes jobs in order to reduce the latency of the construction from 10s of seconds to just seconds.

[blazespinnaker]

That is not a bug. In my opinion it is the expected behaviour of the queue implementation. (You can argue that it is undesirable behaviour, but every alternative I can think of is just as bad).

Not familiar with the arch or DS employed by wube, but I can think of several that would eliminate this 'feature'.