Factorio Forums

To be honest, I 90% think that this is a base issue, not a bug. But I've tried everything I can to prove it's my base goofing up rather than the bot logic and I can't find it. I have to conclude there is something weird going on.

In the screenshot, there is a blue requester chest that I built with a blueprint. At the time of the save file and screenshot, I've been waiting for about 5 minutes for this delivery. You'll notice that this is the only construction job going on. I have plenty of requester chests in supply and if I build another one right next to it (shift click or with blueprint), it will get delivered within 30 seconds. I've fast forwarded the game and let it run for over an hour without any further user input and the box still doesn't get built. The construction robot is clearly assigned but never completes. I've tried using command zoom out to 0.1 to use mouse over to locate the robot but I cannot find it on screen.

As I'm typing this I can think of one possible reason. Could this happen if I blueprinted this using the map view while being at the outpost with my personal roboport on? If so that robot may be trying to fly all that way but realistically should be killed by the biters at some point before getting to base. Also, I'd definitely consider that a bug. While you review this I'll test if this could be that behaviour.

You seem to be missing 61 items for construction. Perhaps Requester Chest is one of those items?

But when you blueprinted it - stationary roboport was already there, right?
EDIT: there is something very weird about your save, definitely thanks for it Looks like when you blueprint more chests - one will always stay ghost.

Correct, this area has had roboport coverage since the beginning of robots. As to your edit: it seems to be only on requester chests though. Everything else gets built normally.
EDIT: looks like I'm on a roll.. This is the third accepted bug in this save

One of these slackers is assigned for the job EDIT: state is wait-for-charge :/

Interesting that you found him. I may have overlooked it when I was trying to find the assigned robot by hovering.
Side note: I continued playing on this save as I built this one missing chest myself. The situation has normalized and I can now build all requester chests. So the bug has disappeared and is only present in that specific save file. (I confirmed by building 9 like you did and they showed up with no construction robots active anymore afterwards)

B4SK3 wrote:Interesting that you found him. I may have overlooked it when I was trying to find the assigned robot by hovering.
Side note: I continued playing on this save as I built this one missing chest myself. The situation has normalized and I can now build all requester chests. So the bug has disappeared and is only present in that specific save file. (I confirmed by building 9 like you did and they showed up with no construction robots active anymore afterwards)

Hi,

do you use smarter bot recharge?
I had this problem too, made a bug report but got no answer and deleted it.

Problem is, it must be reproducable so i'm out.

Greetings, steinio.

I don't think it's a mod issue.
I'm not using any mods changing bot behaviour and had this effect back in 0.15.16 when building my new power plant. Some lazy bots refused to ever place some poles and pipes.
To fix it I used the deconstructor and placed the whole blueprint again.

I found that bot because I can run Factorio in debugger with watches, wasn't that hard But it was an interesting detective. The problem is that one of optimizations led to recharge-queue no longer operating as FIFO, so when you have a lot of bots frequently requesting to recharge at some roboport, the beginning of that queue never gets a chance (so it's not behaving as a queue actually). Fix is on the way.

Yay, glad to hear that! Happy I decided to post this after all.

B4SK3
Fixed. Your requester chest will be delivered in 0.15.22

Awesome, I look forward to it!

glad to see that my -not a bug- is finally considered a bug... and fixed

viewtopic.php?f=23&t=49215

Don't feel disheartened. I've had a couple be deemed not a bug too before being addressed. In fact, I'm only batting about 50% in bug to not-a-bug in my reports.
I'm impressed that you figured out the cause of the bug. Charging never occurred to me as a cause before filing.

Bobanaut wrote:glad to see that my -not a bug- is finally considered a bug... and fixed

viewtopic.php?f=23&t=49215

It's still not considered a bug. A bug is some piece of code we wrote that isn't operating how we programmed it to. In this case it operated exactly as we programmed it to and then it was decided later to change how it operates.

Rseding91 wrote:

Bobanaut wrote:glad to see that my -not a bug- is finally considered a bug... and fixed

viewtopic.php?f=23&t=49215

It's still not considered a bug. A bug is some piece of code we wrote that isn't operating how we programmed it to. In this case it operated exactly as we programmed it to and then it was decided later to change how it operates.

That definition is flawed.
If for some reason you happen to create an infinite loop or buffer overflow the program still is acting exactly like you programmed, yet it defiantly is a bug.
A bug is when expected results differs from actual results. This means results expected by the customer mind you.

Optera wrote:

Rseding91 wrote:

Bobanaut wrote:glad to see that my -not a bug- is finally considered a bug... and fixed

viewtopic.php?f=23&t=49215

It's still not considered a bug. A bug is some piece of code we wrote that isn't operating how we programmed it to. In this case it operated exactly as we programmed it to and then it was decided later to change how it operates.

That definition is flawed.
If for some reason you happen to create an infinite loop or buffer overflow the program still is acting exactly like you programmed, yet it defiantly is a bug.
A bug is when expected results differs from actual results. This means results expected by the customer mind you.

You miss-read what I said: we don't program an infinite loop on purpose, we don't program buffer overflows on purpose. Those would be mistakes the programmer made and would be the definition of bugs.

And you didn't program eternal charging on purpose.

Don't be silly; this was a bug, by all accepted definitions of the term except entomological. "Working as designed", perhaps, but still a bug.