[0.17.6] Stack Inserter Behaviour

[nevjmac]

Blueprint of Dummy Set up, trying to replicate the issue.

https://pastebin.com/8FfqGj0A

I have set up a little dummy circuit to replicate the bigger Picture.

Stack Inserter unloads onto belt and another Stack inserter picks it up, however the distance between these stack inserters change how reliable they are at collecting all thats dropped on the Belt.

The instance I am using this for is for Kovarex enrichment, so having a 1 space between the inserters is obviously ideal so that you can unload and load in the 3 tile space that the centrifuge takes up, but its not ideal if the stack inserter is letting half the the Uranium past.

Here is a Gif as well

https://gph.is/g/4o8kKKE

[Blooper]

It seems like stack inserters are having a harder time keeping up with the belt changes in 0.17 overall. A bunch of blue belt unloading methods no longer work in 0.17 as a result of the changes. Here's an album showing several old designs that no longer work: https://imgur.com/a/JecjdLv

There are new designs that deal with the issue, but the design space is much more limited now. I think stack inserters may need a slight speed increase to compensate for the higher blue belt throughput.

[nevjmac]

Yea you are currently refrencing train unloading and that isn't quite the same as the example I am giving.

if you place 2 stack inserters 1 space apart the loading one can't pick up all the items accurately.

However if you place them 3 spaces apart like in my example, the inserter picks them all up fine

[Rseding91]

Thanks for the report however this isn't a bug.

[nevjmac]

Thanks for the report however this isn't a bug.

Not a bug, so that means you expect the stack inserter to work that way when placed that close to another one?

This was working in 0.16

[Rseding91]

Thanks for the report however this isn't a bug.

Not a bug, so that means you expect the stack inserter to work that way when placed that close to another one?

This was working in 0.16

Yes. I expect the stack inserter to operate as fast as the prototype speed values say it should - which it is. 0.16 had slower belts so the inserter being able to grab items easier makes perfect sense.

[BlueTemplar]

Isn't it kind of weird though that the same kind of inserter that places stuff on the belt can NOT pick it all up again ?
(If placed too close to the first one.)

And this is not some kind of weird belt placement, or weird tricks with undergrounds/splitters or mods :
just an end-game inserter placing and (failing to) pick up stuff on an end-game straight belt...

[Rseding91]

Inserters can drop items faster than they can pick them up.

[BlueTemplar]

Ok, makes sense, I was too stuck in the "game behaviour" vs "realistic behaviour" I guess ?

[Ranakastrasz]

Ok, makes sense, I was too stuck in the "game behaviour" vs "realistic behaviour" I guess ?

Eh, its still realistic. Its way easier to drop an item than pick it up.

[BlueTemplar]

Yes, that's what I meant.

[Twinsen]

The issue was fixed in Version: 0.17.44 for vanilla by making inserters slightly smarter. They are now fast enough to pick up a full transport line off a belt so the timing issue no longer exists.

[NIronwolf]

I'm curious what base vision of the game changed after 2 and a half months to prompt this adjustment. Feels like maybe an honorable mention FFF section.

[tekert]

Its just me, or the stack inserters are slower?
Im doing some preliminary simple tests off a blue belt using stack inserter at 12 stacks:
Belt to Chest

Full Blue belt 45 i/s
v0.17.43 -> 60 ticks (from drop to drop, full cycle, every time droping 12 items)
v0.17.44 -> 64 ticks

Single (closest lane, 22,5 i/s)
v0.17.43 -> 51-61, 56 ticks avg
v0.17.44 -> 55-65, 60 ticks avg

Single (far lane, 22,5 i/s)
v0.17.43 -> 56 ticks
v0.17.44 -> 51-53, 52 avg

Overall, there are 4 ticks slower, and faster picking from the far side of the belt than the closest side, uhmm.

[tekert]

Also the original problem still lingers.

[Cadde]

Any time the hand has to move to pick up something from a belt there is lost time.
The hand is over the far side of the belt in pickup mode, so there's a time loss having to move the hand to the near side to pick up.

You can observe this effect quite nicely with adjustable inserters if you set the pickup one tile away and the drop 3 tiles away. The hand is slower than the inserter rotation speed.

[tekert]

Uhm i see, so now we have to pickup from the far side now to be optimal in some situations.

[disentius]

The issue was fixed in Version: 0.17.44 for vanilla by making inserters slightly smarter. They are now fast enough to pick up a full transport line off a belt so the timing issue no longer exists.

I still consider this a (hopfully fixable) inconsistency

[Koub]

I think the issue might come from the fact that the "grabber" part of the inserter is moving while grabbing a stack (whereas it doesn't move on dropping). It seems as if the inserter tries to get back to a "default resting position" between eack item it grabs. If it just didn't move at all between two items, this would be a smaller issue.

If the angular speed is capped, grabbing on the furthest will be "easier" than grabbing on the closest line : at fixed angular speed, the grabber part will have higher linear speed, so in a given time, will move more.

[Twinsen]

Also the original problem still lingers.

The same thing happens if you place the stack inserter on the opposite side of the belt instead of sideloading.
kovarex insisted this is intended behavior so i'll leave it like this for now.