[0.16.51] inserter interaction with car on belt

Things that has been reported already before.
Post Reply
User avatar
Brathahn
Long Handed Inserter
Long Handed Inserter
Posts: 76
Joined: Sat Aug 02, 2014 1:50 pm
Contact:

[0.16.51] inserter interaction with car on belt

Post by Brathahn » Mon Jan 14, 2019 4:19 pm

Hello,
when you try to unload a car on a belt, the inserter will not grab anything from the car. loading with an inserter to a car on a belt works fine.
i think unloading on a belt should work too. i also know it worked once.
factoriocarbelt1.PNG
factoriocarbelt1.PNG (375.34 KiB) Viewed 169 times

without the belts the inserters work like expected.
factoriocarbelt2.PNG
factoriocarbelt2.PNG (294.45 KiB) Viewed 169 times

User avatar
disentius
Fast Inserter
Fast Inserter
Posts: 163
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: [0.16.51] inserter interaction with car on belt

Post by disentius » Mon Jan 14, 2019 5:58 pm

- put the car on one belt. Inserters get confused with two.
they have more quirks, like "sideloading/unloading":)
cars are strange.gif
cars are strange.gif (2.71 MiB) Viewed 153 times

User avatar
Brathahn
Long Handed Inserter
Long Handed Inserter
Posts: 76
Joined: Sat Aug 02, 2014 1:50 pm
Contact:

Re: [0.16.51] inserter interaction with car on belt

Post by Brathahn » Mon Jan 14, 2019 10:34 pm

You are right. It works fine with one belt. Thanks!
But i think it should work with two belts too.

Jap2.0
Smart Inserter
Smart Inserter
Posts: 1923
Joined: Tue Jun 20, 2017 12:02 am
Contact:

Re: [0.16.51] inserter interaction with car on belt

Post by Jap2.0 » Tue Jan 15, 2019 12:52 am

There are 10 types of people: those who get this joke and those who don't.

Allaizn
Inserter
Inserter
Posts: 41
Joined: Sat Mar 03, 2018 12:07 pm
Contact:

Re: [0.16.51] inserter interaction with car on belt

Post by Allaizn » Tue Jan 15, 2019 4:11 am

Let me explain what is happening here, since it's not intuitive, but also very unlikely to be changed:

Inserters perform rather expensive calculations which is why the results of many of those are saved rather then recomputed every time they're needed. Two of these results are the entity an inserter is going to pickup from and the entity that the inserter is going to drop his items onto/into. Once it saved those, it'll only perform the much less costly check of whether or not it is able to still interact with them (e.g. they could be deconstructed, or moved away too far in case of cars).
The other thing to know is what happens when one of those two saved entities isn't valid anymore, e.g. how the inserter searches for a new entity. It's not surprising that it looks which entities are in range of it's pickup/ dropoff spot, but what may be surprising is how the inserter decides when multiple entities are possible:
  • In case of both a car and a belt being in range at the dropoff, the inserter will always prefer the car.
  • In case of both a car and a belt being in range at the pickup, the inserter will always prefer the belt.
This explains the behaviour you're seeing, since even if the car is already stopped at the correct position, the right inserter will always bind to the belt instead and completely ignore cars.
Another thing to note is that once you move the car away and give the left inserter any reason to start his swing (and thus decide to insert onto the belt), it'll get similarly stuck on the belt and ignore cars for all eternity.

The workaround for this problem is to drop/pickup from the tile beside the belt (either orientation usually works) and exploit the nice and large hitbox size of car, as seen in the reply by disentius. The inserters will never have the chance to break since they can't "focus" on the belts. You can also run the risky business of inserting onto a car belt directly, by making sure to circuit-deactive the inserter at all times that no car is present, but that is far from easy.

Note that this behaviour will very likely never change due to performance reasons: it's really expensive for the inserter to search for a car in range (or any entity for that matter), and the only way for this to work "correctly" is for the inserter to do that search every single tick - not only is each search expensive, but it would also prevent the inserter from ever sleeping, which is an extra hit to performance. Considering that inserters are regarded as the current enemy no. 1 of UPS by many mega base builders (and the Devs likely know that), we're very safe to assume that this behaviour will not change.

Post Reply

Return to “Duplicates”

Who is online

Users browsing this forum: No registered users and 1 guest