Factorio Forums

Notxarb wrote: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.

And then the inserter picks up 12 iron ore to insert into the furnace and the furnace runs out of fuel. Now the inserter is stuck trying to deposit the iron ore and can't pick up some more coal or wood and you have a deadlock.

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

I notice that too. What I haven't tested yet is how the speed is computed.

Does the inserter have a fixed angular speed and with that setup the angle is simply smaller?
Or does the inserter have a fixed linear speed and with that setup the distance is simply smaller?

The point is: With fixed angular speed using a 3 long inserter would reduce the angle even further, making it even faster. WIth linear speed it would make difference.

Another thing I noticed is that changing the length of the arm takes really long. So picking up at length 3 and inserting at length 1 makes it really slow. But in most cases you have a larger pickup or drop of area. E.g. an assembler is size 3x3 and anywhere is good for pickup or drop off. Making the pickup and drop of length the same makes a huge difference.


This changes the whole factory design of having belts run 1-2m from the assembler with insertes between them. It's better to have the belt directly next to the assembler and then inserters to the side of the assembler.

mrvn wrote:I notice that too. What I haven't tested yet is how the speed is computed.

Does the inserter have a fixed angular speed and with that setup the angle is simply smaller?
Or does the inserter have a fixed linear speed and with that setup the distance is simply smaller?

A little dreailing of the topic, but here's a quick answer with proof for you.
Angular speed seems to be fixed. In this simple setup the farther stretched the insert was the faster it moved the 10k plates.
The difference between the 180°, 90° and 50° is huge. There's not much gain between 50° and 37°.

Optera wrote:

mrvn wrote:I notice that too. What I haven't tested yet is how the speed is computed.

Does the inserter have a fixed angular speed and with that setup the angle is simply smaller?
Or does the inserter have a fixed linear speed and with that setup the distance is simply smaller?

A little dreailing of the topic, but here's a quick answer with proof for you.
Angular speed seems to be fixed. In this simple setup the farther stretched the insert was the faster it moved the 10k plates.
The difference between the 180°, 90° and 50° is huge. There's not much gain between 50° and 37°.

2017-07-24-14-15-03-9872505.jpg

You can do better. No need to have that gap between chests. Then you can go from 180° (vanilla inserter with gap) to 45°, 25° and 18.5°. That is nearly 10 times the speed (9.73 times).

mrvn wrote:You can do better. No need to have that gap between chests. Then you can go from 180° (vanilla inserter with gap) to 45°, 25° and 18.5°. That is nearly 10 times the speed (9.73 times).

To get precise measurements you minimize variables like distance between chests.
If you exclude 180° vanilla inserter and start with 90°the speed gain is less visible and nowhere as impressive.

Koub wrote:[Koub] Moved to off topic.

Before this happens, can we get a consensus on whether the OP is a bug or a suggestion? I vote bug.

featherwinglove wrote:

Koub wrote:[Koub] Moved to off topic.

Before this happens, can we get a consensus on whether the OP is a bug or a suggestion? I vote bug.

That's not how bugs work bugs are things which we've intended to work one way but don't work that way. This is working fully as we intended it to. It even has game mechanics you can utilize to increase throughput more if you want.

Rseding91 wrote:

featherwinglove wrote:

Koub wrote:[Koub] Moved to off topic.

Before this happens, can we get a consensus on whether the OP is a bug or a suggestion? I vote bug.

That's not how bugs work bugs are things which we've intended to work one way but don't work that way. This is working fully as we intended it to. It even has game mechanics you can utilize to increase throughput more if you want.

The suggestions so far are:

1) buffer chests, which eliminates the time to pick up items of a belt but not the time to turn around
2) my idea of using circuits to time inserters perfectly to trigger the next inserter right before an inserter drops items each time

The second is only an idea and will only work if the timing works out perfectly. It would improve on the first suggestion by one handful of items. All of this still wouldn't be enough for some fast assembly cycles.


Since modules appear to increase the input / output buffer size could you tell us please if mods can alter the size too? And if so how? I see this mainly as a problem with e.g. Bob's mods, which has far faster assembler. So making the faster assembler have bigger buffers would be a solution.

mrvn wrote: The suggestions so far are:

1) buffer chests, which eliminates the time to pick up items of a belt but not the time to turn around
2) my idea of using circuits to time inserters perfectly to trigger the next inserter right before an inserter drops items each time

The second is only an idea and will only work if the timing works out perfectly. It would improve on the first suggestion by one handful of items. All of this still wouldn't be enough for some fast assembly cycles.


Since modules appear to increase the input / output buffer size could you tell us please if mods can alter the size too? And if so how? I see this mainly as a problem with e.g. Bob's mods, which has far faster assembler. So making the faster assembler have bigger buffers would be a solution.

This is not exclusive to bobs. All 0.5 and some 1.0 recipes in vanilla have the issue of stuttering machines in max beacon setups.
Buffer chests only make the stutters shorter. The real problem is input buffer size not growing fast enough alongside crafting speed. As far as I know mods can't change input buffer sizes. All we modders could do to hide the problem is scaling all affected recipes by 10: 10x energy/time, 10x input, 10x result.
The only real fix is for the devs to change minimum input buffer (when inserters start to feed machines) to properly scale with crafting speed.

Rseding91 wrote:

featherwinglove wrote:

Koub wrote:[Koub] Moved to off topic.

Before this happens, can we get a consensus on whether the OP is a bug or a suggestion? I vote bug.

That's not how bugs work bugs are things which we've intended to work one way but don't work that way. This is working fully as we intended it to. It even has game mechanics you can utilize to increase throughput more if you want.

I don't see any game mechanics which increase the throughput in the situation described by DaveMcW (a way better factoriozer than I am):

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

I find it very hard to believe that's intended behaviour. If it is, can you explain the game mechanic I'm missing that allows us to increase throughput in this situation?

...or is it the intended behaviour that we have a throughput bottleneck there is no way to overcome? If so, "game mechanics you can utilize to increase throughput more" is a contradiction within your comment.

Am I missing something, or are you?

What if there was a way to configure number of things a machine produces (kinda like hand crafting you can craft 1 or 5). WIthout requiring a separate recipe of 1 or 5 of an item. (even 3 would probably fix this) ... but in the case of vanilla as it is, configuring the stack size of the inserter to pick up fewer items would help, since it wouldn't pick up excessive products (could cut the delay in at least half, and more practically setting it to 4 would limit it to 4 would be 1/3 the delay)

Re fast adjustable inserters - the original 'this is really fast' idea with adjustable inserters. isn't as fast as it could be, it's much longer to move the handle in and out than to turn; and going from 2 away to one tile away either horizontally or vertically slows it down; which the speed test post didn't really address that since source and target are the same distance also.

going to and from two squares that are the same color is fastest and the two purple in the corner is ultimate fast least angle, no distance change.

d3x0r wrote:What if there was a way to configure number of things a machine produces (kinda like hand crafting you can craft 1 or 5). WIthout requiring a separate recipe of 1 or 5 of an item. (even 3 would probably fix this) ... but in the case of vanilla as it is, configuring the stack size of the inserter to pick up fewer items would help, since it wouldn't pick up excessive products (could cut the delay in at least half, and more practically setting it to 4 would limit it to 4 would be 1/3 the delay)

Re fast adjustable inserters - the original 'this is really fast' idea with adjustable inserters. isn't as fast as it could be, it's much longer to move the handle in and out than to turn; and going from 2 away to one tile away either horizontally or vertically slows it down; which the speed test post didn't really address that since source and target are the same distance also.

going to and from two squares that are the same color is fastest and the two purple in the corner is ultimate fast least angle, no distance change.

The attachment inserter-speed.jpg is no longer available

Don't forget the pickup and drop offset. Picking up things from one side of a belt makes the arm shorter, the other side longer. Chests I think take whatever length they have. There might be tiles with different colors that are the same length if they have opposite offsets. I'm pretty sure that picking up 3 from the left and dropping 3 from the left and one down with the right offset does not change the length and is less angle I think than the two purple in the corner.

The ultimate fast inserter I think would be this:

Nothing to disagree with, except that the thread is about a vanilla bug that the devs can't tell is a bug, or a vanilla mechanic that appears to be a bug at least until someone explains to me how it's supposed to work. And yes, Bob's inserters are fickung asewome

It's not a bug. Just a designed limit (only buffer 2 cycles worth) that doesn't work for high speed cycles.

Stack inserter is not supposed to be the best inserter in the game that is used everywhere, that's why stack bonus research also affects non-stack inserters. Fast inserter would manage to supply the assembling machine fast enough. That is why it is not a bug.
If you put 4 speed modules lv3 to the AM, you'd need stack inserter with stack limited to 6.

The following may not be 100% appreciated -- but, for the record, I have been resisting the urge to say this for over a year. I think, for a smart-ass such as myself, I made a respectable effort to resist but I'm giving in to my inner pedant.

It's time we have a candid discussion about the significance of the term bug, as in:

hypothetical speaker wrote:A bug in the software caused it to respond to certain types of user queries with a dialog-box containing only the word 'no' when a user query yielded no results. Users interpreted this response as a curt refusal to answer the query at all, and perceived it as "impolite."

TLDR: the term "bug" pretty clearly refers to detrimental interactions between a system with unforeseen environmental factors in deployment; whether, when the "bug" emerges, the system is working as designed, or not, is not definitionally important.

To see why, consider that the term pre-dates computers. Laurence Zuckerman wrote in a delightful article about this term in the April 22, 2000 edition of the New York times:

Laurence Zuckerman wrote:[Author and Yale University librarian Fred R. Shapiro] point[s] out that the Oxford English Dictionary includes a reference to an interview with Thomas Edison in an 1889 edition of the Pall Mall Gazette in which the inventor refers to finding a ''bug'' in his phonograph. The article went on to define the term as ''an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble.''

I think, if we reflect on this, we will see that term almost certainly emerged as a slang expression shared amongst engineers, with whom it became popular because it immediately -- but not without a moment of initial confusion and mental processing -- evoked an amusing (but false) non-technical explanation and metaphor for a broad array of engineering problems, just as the inner quotation describes: an image of a physical bug crawling into some sort of clockwork mechanism and "gumming up the works."

If I'm right (and I'm pretty sure I am), then the assertion Wube has rather steadfastly maintained here in the Factorio forums, expounded explicitly above, is wrong. To wit:

Rseding91 wrote:

DaveMcW wrote:(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.

The term is not being improperly colloquialized by Factorio users to refer to a broad array of non-design problems. Indeed, quite the opposite: it is, if anything, being improperly formalized by Wube to refer only to design problems.

We can call the types of problems RSeding91 refers to above "code-algorithmic" or whatever we want -- that's just semantics. But linguistically speaking (no pun intended), I'm quite confident that bug popularly and correctly refers to behavior of a system which fails to achieve useful results, while suggesting such behavior may have come to light only after deployment. In other words, standard, modern usage is more-or-less agnostic as to whether or not the system functions correctly in laboratory conditions -- to qualify as a bug only requires that the system not function adequately once deployed.

I would also argue that the term additionally connotes that the designer is at least partially blameless for the difficulty, suggesting that a difficult cognitive leap beyond basic engineering considerations may have been required to predict the emergence of the problem. Hence it is probably intended as a way to politely break the news to an engineer that they made an error, without impugning their technical skills, something that engineers can tend to be pretty sensitive about.

golfmiketango wrote: The term is not being improperly colloquialized by Factorio users to refer to a broad array of non-design problems. Indeed, quite the opposite: it is, if anything, being improperly formalized by Wube to refer only to design problems.

I agree. But my question as to whether it was the devs' intent to have a throughput bottleneck that can't be overcome hasn't been answered to my satisfaction. This...

Rseding91 wrote:

featherwinglove wrote:

Koub wrote:[Koub] Moved to off topic.

Before this happens, can we get a consensus on whether the OP is a bug or a suggestion? I vote bug.

That's not how bugs work bugs are things which we've intended to work one way but don't work that way. This is working fully as we intended it to. It even has game mechanics you can utilize to increase throughput more if you want.

Perhaps, "This is working fully as we intended it to" is true, however, "It even has game mechanics you can utilize to increase throughput more if you want" is false. (If he's referring to "[mrvn's] idea of using circuits to time inserters perfectly to trigger the next inserter right before an inserter drops items each time", I need to see a demonstration, because I don't think this is possible. That and I hate circuit networks.) I have no doubt about Rseding91's technical skill. I just wish he were as sensitive as that about his honesty being impugned that he would answer my question: If this isn't a bug and Wube actually wants inserters waiting until it is too late to keep a machine running constantly, what way to increase throughput am I missing?

featherwinglove wrote:Perhaps, "This is working fully as we intended it to" is true, however, "It even has game mechanics you can utilize to increase throughput more if you want" is false. ... what way to increase throughput am I missing?

Put a chest between the belt and the assembling machine so the inserter doesn't waste time with slow belts.

Rseding91 wrote:

featherwinglove wrote:Perhaps, "This is working fully as we intended it to" is true, however, "It even has game mechanics you can utilize to increase throughput more if you want" is false. ... what way to increase throughput am I missing?

Put a chest between the belt and the assembling machine so the inserter doesn't waste time with slow belts.

I'm not sure if this is enough once you reach speed of 7+ on things like copper wire.
Swing time for fast inserter is to long to deliver materials for such quick crafting item at high speeds. And it won't trigger until there is enough left for only 2 crafts and by then it's to late.

Rseding91 wrote:

featherwinglove wrote:Perhaps, "This is working fully as we intended it to" is true, however, "It even has game mechanics you can utilize to increase throughput more if you want" is false. ... what way to increase throughput am I missing?

Put a chest between the belt and the assembling machine so the inserter doesn't waste time with slow belts.

It has been said before and I will say it again.
Feeding machines from a chest only mitigates the problem for slower machines. Fully beaconed setups for fast recipes ike Copper Wire, Gear Wheels become too fast for inserters to react resulting in stuttering machines.

The only "fix" we modders can offer is to enable loader or change these recipes to craft 10x the amount in 10x time.
The real fix has to come from you devs to make inserter react sooner to emptying input buffers of such fast machines.