Factorio Forums

Build 35382 (seen this in earlier 0.16 builds/versions also)

Sometimes inserters just get stuck and don't pick up items from chests/factories. Have seen it multiple times already. See image attached for sample situation.
Couldn't find specific logic for this.

I'm not sure how to repro this. However in the save attached, character stands right by the sample chest+inserter.

Thanks for the report. The inserter is sleeping in the curved rail because inserters are setup to prioritize interacting with rails over anything else. See:

You can fix it by changing the curved rail to be straight for 1 more piece then turning.

Thank you for showing how this can be debugged will use it further.

Problematic part is that if I merely pick up and place inserter again, it will start working as expected.
1) I had similar issues with no tracks nearby. So this doesn't seem to be more reason.
2) shouldn't inserter behavior be deterministic? I mean same setup should always work the same way.

(Replying from phone, sorry if not too explicit here)

Ardagan wrote:Thank you for showing how this can be debugged will use it further.

Problematic part is that if I merely pick up and place inserter again, it will start working as expected.
1) I had similar issues with no tracks nearby. So this doesn't seem to be more reason.
2) shouldn't inserter behavior be deterministic? I mean same setup should always work the same way.

(Replying from phone, sorry if not too explicit here)

It is deterministic. If it wasn't it would desync in multiplayer.

The state the game is in when you place the inserter is different virtually every time you place it which changes what it does next.

Rseding91 wrote:

Ardagan wrote:Thank you for showing how this can be debugged will use it further.

Problematic part is that if I merely pick up and place inserter again, it will start working as expected.
1) I had similar issues with no tracks nearby. So this doesn't seem to be more reason.
2) shouldn't inserter behavior be deterministic? I mean same setup should always work the same way.

(Replying from phone, sorry if not too explicit here)

It is deterministic. If it wasn't it would desync in multiplayer.

The state the game is in when you place the inserter is different virtually every time you place it which changes what it does next.

My assumption here is that the same setup of objects on map, should always result in same behavior of all elements of setup. So regardless whether I replace inserter, or not, it should still behave the same. Like if inserter was putting object on rails -- it should always do so, regardless of how many times times I replace it with another inserter.

Is there any explicit reasoning why we have current behavior in place?

Couldn't inserters "look" for a distance to object and then decide if they can actually place an item there. Obviously, it's too far away and there is object nearer it that it can place items into.

ethernal wrote:Couldn't inserters "look" for a distance to object and then decide if they can actually place an item there. Obviously, it's too far away and there is object nearer it that it can place items into.

I believe it's because the rail's bounding box extends into that tile, even though it's only a small amount.
The bounding boxes aren't planned to be changed, because that would break stuff... wait...

Coming here from a Reddit post I made earlier today, where I also assumed this behavior was a bug: thread link, YouTube minimal repro.

From upthread:

Ardagan wrote:So regardless whether I replace inserter, or not, it should still behave the same. Like if inserter was putting object on rails -- it should always do so, regardless of how many times times I replace it with another inserter.

...I think that sums up exactly my expectations as well. I understand that the behavior is "deterministic" in the Factorio-internal sense that it doesn't cause multiplayer desyncs. However, as a player the fact that the drop target for the inserter depends on the build order of the chest and / or rails is really quite confusing.

I think the common use-case is pretty illustrative of why this is painful - "If I blueprint this and build it with bots, does it work?" - and in this case the answer is "Sometimes, it depends on which bot(s) build their item fastest". That's not particularly rewarding as a player.

Anyway! This is me dredging up a thread from 2+ years ago (and I apologize!) but it's really the first time I've ever encountered something I'd consider a bug in Factorio, so I felt like it was worth chiming in and nudging the feedback. Cheers!

Coming here from my duplicate report and adding another voice in opposition to build order dependent behavior here.

This bug happened in one of Nefrums 100% attempts recently: https://clips.twitch.tv/GrotesqueNastyM ... BkM-ttI7Ur ("Waiting for train" can be seen 8s into the video)
I also managed to reproduce it [1.1.58], and even if you put a wagon onto the curved rails, the inserter will remain stuck instead of inserting into the wagon.
You can fix the broken inserter by reconstructing it.

This doesn't just apply to curved rails. It seems to apply any time an inserter could have two targets. I wouldn't mind if it was consistently prioritized, but it being dependent on build order doesn't seem reasonable.

Copy blueprint
If you build the wagon first, the inserter targets the wagon. If you build the underground first, the inserter targets the underground.