[0.15.23] inserter waits too long

[Nexarius]

[Rseding91]

The inserter waits for the assembling machine ingredients to be < 2x the required items. Once that happens the inserter activates and starts grabbing the iron plates.

The problem comes from the inserter having to grab a full hand worth of iron plates which takes some time.

You can either limit the stack size of the inserter, use a fast inserter which is limited to a max of 3 or use a chest as a buffer so the inserter doesn't need to grab each item off the belt.

[Nexarius]

The inserter waits for the assembling machine ingredients to be < 2x the required items.

Why not increase that for stack inserters?

[DaveMcW]

Even with a chest or fast inserter, it will wait too long if the assembling machine produces 2 recipes in less than 14 ticks.

(Also, how is the stack inserter being worse than a fast inserter not a bug?)

[Rseding91]

(Also, how is the stack inserter being worse than a fast inserter not a bug?)

Because bugs are things we programmed that aren't working as we intended for them to work. In this case it works exactly as it was programmed to: wait until machine has < 2x ingredients then turn on and work.

[Nexarius]

(Also, how is the stack inserter being worse than a fast inserter not a bug?)

Because bugs are things we programmed that aren't working as we intended for them to work. In this case it works exactly as it was programmed to: wait until machine has < 2x ingredients then turn on and work.

As far as I understand the game it's intended that an assembler can run without pause if all resources are available and the inserters are fast enough but it doesn't work that way because the inserter is just waiting -> bug.

[tamanous]

Before arguing for definitions: will this probably be dismissed when moved from bugs to suggestions?

Nevertheless,

+1

[Tekky]

I think it would be best if it were possible to override this default behavior of the assembler (only asking for input when less than 2x the ingredients of the receipe are inside the assembler).

It should be possible to override this factor (which defaults to 2). The interface for overriding this on assemblers should be similar to the interface of overriding stack size on inserters. Setting the factor to zero should remove all limitations, i.e. the inserters will insert the same amount that is possible to insert by hand.

[featherwinglove]

(Also, how is the stack inserter being worse than a fast inserter not a bug?)

Because bugs are things we programmed that aren't working as we intended for them to work. In this case it works exactly as it was programmed to: wait until machine has < 2x ingredients then turn on and work.

As far as I understand the game it's intended that an assembler can run without pause if all resources are available and the inserters are fast enough but it doesn't work that way because the inserter is just waiting -> bug.

I agree with Nexarius. I'm pretty sure you guys didn't intend for fast machines to spend time waiting for incredients when matched up with inserters and belts that are theoretically overkill for the machine being fed.

[tamanous]

Maybe that was intended, but coded otherwise. Still it does not count as a bug, because everything works as programmed. Changing the (correct working) program is not concerned a bug request, but a suggestion. As there are many many suggestions, the problem of choosing witch to implement occurs before the problem of how to implement. As this particular one is - probably - of minor importance, it is less likely to be implemented (soon or ever).

---

Another close-to-good ingame-workaround for some of these kind of problems is splitting the input belts and using more than one inserter. Fast inserters with low stack size kick in fast when items in the machine are depleted, while (in parallel) stack inserters start working and deliver a bit later, but more items.

[featherwinglove]

Maybe that was intended, but coded otherwise. Still it does not count as a bug, because everything works as programmed.

That's the definition of 99% of bugs. In most cases, the program is working as coded, but the intention of the programmer didn't translate perfectly through the code. If it's the devs' intent that the machine should be working at top speed when the inserters feeding it have the necessary throughput to keep it fed, it is a bug when it is not doing that. It is a bug.

[Lav]

I don't understand the problem. Stack inserter is explicitly designed to be not at it's best when feeding from a belt. It is a known fact of life, there are threads and wiki articles about this. So why is it so surprising for so many people that it's indeed not at it's best when feeding from a belt?

[featherwinglove]

If that's the intent, then it's not a bug. But I haven't seen a dev yet say that that's the intent. IMHO, stack inserters seem designed to work with the logistics network and/or train networks rather than with conveyor belts.

Also DaveMcW claims that the machine can wind up waiting for a fast inserter or stack inserter even in the case where it's pulling from a chest, if the machine is fast enough to craft the recipe twice before it swings around from the chest, 14 ticks. This will happen at a crafting speed of 2.2ish or greater with half-second recipes. I haven't tested it, but if he's right, then it's still a bug even if the intent is that stack inserters stall with belts.

[mrvn]

If that's the intent, then it's not a bug. But I haven't seen a dev yet say that that's the intent. IMHO, stack inserters seem designed to work with the logistics network and/or train networks rather than with conveyor belts.

Also DaveMcW claims that the machine can wind up waiting for a fast inserter or stack inserter even in the case where it's pulling from a chest, if the machine is fast enough to craft the recipe twice before it swings around from the chest, 14 ticks. This will happen at a crafting speed of 2.2ish or greater with half-second recipes. I haven't tested it, but if he's right, then it's still a bug even if the intent is that stack inserters stall with belts.

I guess at those speeds you have to start programming your inserters. Have 2 inserters and add some circuit logic so they are forced to work out of phase. You have to time it so that first one inserter activates, then, just before/as it drops its items, the second inserter activates and picks ups more items too. The timing should be such that the assembler reaches <2x items just before/as the inserter drops items into it so that the second inserter starts moving too.

Could be real tricky to get right and not always possible. But should be fun to figure out.

[Engimage]

I am for the configurable automatic buffer. Since my first day in Factorio.

But to negate the effect you see you can use a buffer chest near assembler so that one inserter puts items into the chest (which can be limited to 1 stack) and another from chest to assembler. Yes it takes space and power but it can help if this is critical.

[mrvn]

I am for the configurable automatic buffer. Since my first day in Factorio.

But to negate the effect you see you can use a buffer chest near assembler so that one inserter puts items into the chest (which can be limited to 1 stack) and another from chest to assembler. Yes it takes space and power but it can help if this is critical.

The inserter still has a minimum time it needs to turn around from the chest to the assembler. Earlier someone said it takes 14 ticks to turn. If the assembler runs more than 2 cycles in 14 ticks then the inserter will be too slow. Chests or no chests or multiple inserters won't solve this 100%. There will always be a gap of (14 - 2 cycles) ticks.

[Optera]

I am for the configurable automatic buffer. Since my first day in Factorio.

But to negate the effect you see you can use a buffer chest near assembler so that one inserter puts items into the chest (which can be limited to 1 stack) and another from chest to assembler. Yes it takes space and power but it can help if this is critical.

The inserter still has a minimum time it needs to turn around from the chest to the assembler. Earlier someone said it takes 14 ticks to turn. If the assembler runs more than 2 cycles in 14 ticks then the inserter will be too slow. Chests or no chests or multiple inserters won't solve this 100%. There will always be a gap of (14 - 2 cycles) ticks.

Isn't this exactly what a configurable buffer level / inserter activity threshold would fix?

Inserters starting at way too low levels is really annoying in any bob's game. It also happens in my vanilla base with things like copper cables.
Currently the only way to feed those fast machines is to use loaders, which has it's own problem when switching adjacent beacons on and off.

[Lubricus]

Optera
going off topic but with this inserter settings in bobs mods they are insanely fast

[Notxarb]

See, what the devs should do is make it so that inserters pick up a full hand of items first, bring it over to the machine, and then decide whether to deposit the items or not. That way, the items are immediately available once the machine goes below <2x the amount of items required, and while it uses those the inserter can go and get another hand ready.

[Optera]

Optera
going off topic but with this inserter settings in bobs mods they are insanely fast

This little trick to reduce rotation speed is nice, but doesn't really help for high speed machines. Inserter simply start feeding too late regardless.
Like I said, loaders are the solution when using mods, but for vanilla gameplay there is no workaround.