Increase trigger point for inserting into machines

[vanatteveldt]

The stack inserter made it possible to consider belt-based logistics again for high-throughput factories (i.e. assemblers with high productivity and speed boosts).

A stack inserter can insert >10 items per second between belt and assembler, which is enough for the input and output of a highly boosted green circuit line (4 prod in all assemblies and surrounded by 6 speed beacons).

Unfortunately, current inserter behaviour means that it starts inserting when the input buffer < 2*recipe input. In the case of green circuits, this means that it only inserts iron when it has 0 or 1 iron left. However, the stack inserter takes time to collect the iron and insert it, and since the assembler is going so fast it will have depleted the 2 iron (1 in buffer, 1 in recipe) before the inserter provides new plates. As a result, there is a small pause in production after every 12 plates, even though the inserter has sufficient throughput if it would not wait until the buffer is fully depleted. See viewtopic.php?f=18&t=30332 for a fuller discussion and pictures

In my opinion, this is not desired, as the point of an input buffer is that the assembler should be able to keep producing provided there is enough througput of materials.

Suggestion: change the trigger of inserters so they will insert into a machine when the input count <= inserter_stack_size.

This allows any inserter to keep inserting as fast as the machine can use the materials since if the machine uses stack_size in less time than the inserter can collect and insert input, the inserter can't keep up with the machine anyway. On the other hand, this also makes sure that no unneeded materials are inserted, and start-game behaviour is identical to the current trigger (at least for the single item recipe case).

Buffer chests are a workaround, but in my opinion they should be needed only when the assembler requires more input than the inserter can provide from a belt (as container -> container is about twice as fast as belt <> container)

(edit: clarified suggestion to be about the inserter trigger point, not the machine input buffer)

[OdinYggd]

I'd much prefer a configurable cache size. That way early in game I can tell things to only load enough material for the next object to be made, while later in game my high volume production stands can run with full stack buffers in them to make sure they never stop.

[BlakeMW]

I think the cache size should be based on the real consumption rate of the item in the machine, for example a prod+speed assembler 3 making electronic circuits consumes 11 iron/s, so 11 would make a good starting point for the input buffer. Then that should be min'd with some sensible number (maybe "20"), so if you're making satellites in a fast assembler it doesn't want to buffer up a quadzillion solar panels.

[Klonan]

The stack inserters failing in this way is just a downside of their design, it isn't all advantages.

In these cases a buffer chest works, but also using multiple fast inserters works better than a single stack inserter

[orzelek]

The stack inserters failing in this way is just a downside of their design, it isn't all advantages.

In these cases a buffer chest works, but also using multiple fast inserters works better than a single stack inserter

It seems for me that stack inserter was pre-nerfed with this.
Also using fast inserters (even two) doesn't help in some scenarios. Might be caused by the fact that they are modded (stack of 5 items) but even with 2 of them there was a stall in electronic board production when using bob's mods. Only way to get no stall is to use express inserter since it's faster.

Making people use chest before inserter and belt gives even more power to bots... since you could use just chest and drop the belt completely.

Is it a big problem to make assembling machine available for input materials insertion a bit earlier?

I remember that something like that was meant to be done for high speed assemblers - to allow bigger stacks of input/output so that inserters can load faster. Currently it seems that inserters can load more (2 stack inserters will put two full stacks into input slot) but they still wait for input slot to drop to value that ignores stacks.

[Engimage]

I'd much prefer a configurable cache size. That way early in game I can tell things to only load enough material for the next object to be made, while later in game my high volume production stands can run with full stack buffers in them to make sure they never stop.

This ^^
I wanted to make it a separate suggestion but here it comes.
Every assembler should have an option to increase input/output cache. Actually the cache already has the limit which is 1 stack of items and you can use it if you manually insert materials. What is needed is increasing the value for automatic provisioning so that "supply request" for inserters should trigger at higher values.

[vanatteveldt]

I'd much prefer a configurable cache size. That way early in game I can tell things to only load enough material for the next object to be made, while later in game my high volume production stands can run with full stack buffers in them to make sure they never stop.

This ^^
I wanted to make it a separate suggestion but here it comes.
Every assembler should have an option to increase input/output cache. Actually the cache already has the limit which is 1 stack of items and you can use it if you manually insert materials. What is needed is increasing the value for automatic provisioning so that "supply request" for inserters should trigger at higher values.

Personally, I don't think this is a good solution. This is an extra option, which needs UI support, be included in blueprints, etc. My suggestion (to set input buffer to inserter stack size +1) achieves the same results: no wasted material in early game, no throughput problems in later game (assuming input is uninterrupted), and "most" users should never even notice.

If you want the assembler to keep working even if input is intermittent, that is where a proper buffer chest should get in. This fits with the factorio philosophy (AFAICT) that nothing should be automatic, and everything should be automatable. IOW: Solving puzzles is the goal of the game, not of the devs

[BlakeMW]

The problem with the buffer chest, as already mentioned by orzelek, is once you have a buffer chest you may as well get rid of the belt and input inserter and use logistic bots.

The 0.13 changes were a big equalizer between belts and bots, but this tends to swing the favor back to bots for high throughput assemblers. It's not like bots need help, they're still by far the best solution for high-throughput over short distances.

[vanatteveldt]

@Blake, yes, if you need buffer chests belts are less attractive. But if my suggestion is adopted you won't need buffers if you can keep the belt full all the time. The only reason to use a buffer is to buffer an intermittent stream, i.e. apparently you can keep it more-than-full some of the time but not full enough other times, and you can't use the belt as buffer. That is not a very common situation in a well designed factory, so I don't think buffer chests between belt and assembler are ever really needed (if the input buffer is increased to >inserter stack size)

[orzelek]

I think that buffer would need to be a bit more then stack size. And it might be already - it's only the automatic trigger for inserter thats wrong.
I do belive I seen two stack inserters react at same time, grab full hand of stuff and put it into assembler at once. Problem is that they reacted when there was enough materials for about 0.15-0.2 second or less of crafting.

Inserters should react when amount of input buffer drops below amount required for half a second (or even a second) of constant working of assembler. Ideally it would be based on actual recipe & assembler speed.

[Zeblote]

I think the problem is just that the input buffer doesn't scale with how fast the assembler crafts * how fast the recipe can be crafted. It should always be able to sustain the assembler for something like 5 seconds, or enough resources to craft one item, whichever is more.

For example:

-Level 1 assembler crafting iron gears. 0.5 crafting speed * 2 items per second * 5 seconds * 2 plates = a buffer of 10 plates.
-Level 3 assembler with speed modules crafting electronic circuits. 2.5 crafting speed * 2 items per second * 5 seconds * (1 iron plate + 3 copper wire) = a buffer of 25 iron plate and 75 copper wire.
-Level 1 assembler crafting rocket control unit. It takes 60 seconds to craft the item, so we buffer the resources for one of them. Buffer of 1 processing unit and 1 speed module.

[Rysith]

I think the problem is just that the input buffer doesn't scale with how fast the assembler crafts * how fast the recipe can be crafted. It should always be able to sustain the assembler for something like 5 seconds, or enough resources to craft one item, whichever is more.

This - it seems like a really easy fix would be to multiply the desired input buffer by the current crafting speed of the assembler (with a min of 1, obviously)

[vanatteveldt]

You don't need to take the recipe speed into account.

Sorry if my suggestion wasn't completely clear. What I mean is: change the inserter trigger so it inserts when input <= stack_size .

Assume that the inserter has stack size 12. The inserters comes into action once buffer=12. If it can insert before the buffer hits zero, the assembler can continue processing, and the new buffer will be increased with 12, and the inserter will wait until it drop to 12. If it can't insert before the buffer hits zero, apparently the assembler uses more than 12 items in the time of a single swing, which means that the inserter throughput is smaller than the assembler input and the inserter can't keep up regardless of the buffer. In other words, this guarantees that if the assembler can use all the input, the inserter will work full time, while the buffer is never more than needed to keep the machine going.

I'll clarify the original suggestion to make clear that I mean the inserter trigger, not the input buffer per se.

[BlakeMW]

That's a really good suggestion. And if you don't want (up to) 26 items buffered, just use a non-stack inserter and it'll only buffer up to 6.

[ssilk]

My opinion about this suggestion: For expensive items this suggestion is a complete fail. Well, you can argue that the most players don't produce the expensive stuff in masses (and use stack inserter) but I think it should work in all cases. And this suggestion will not.

[Klonan]

My opinion about this suggestion: For expensive items this suggestion is a complete fail. Well, you can argue that the most players don't produce the expensive stuff in masses (and use stack inserter) but I think it should work in all cases. And this suggestion will not.

Yes, we discussed the issue, and the 'correct fix' will be reworking the belt->inserter wake mechanic, increasing the overload inventory would only treat the symptom, not the cause.

[Zeblote]

Sorry if my suggestion wasn't completely clear. What I mean is: change the inserter trigger so it inserts when input <= stack_size.

You're right, this can work. However it's very important that it is input <= combined stack size of all input inserters, otherwise placing more inserters would not help load the machine faster - they would all trigger at the same time - all too late.

[vanatteveldt]

My opinion about this suggestion: For expensive items this suggestion is a complete fail. Well, you can argue that the most players don't produce the expensive stuff in masses (and use stack inserter) but I think it should work in all cases. And this suggestion will not.

Yes, we discussed the issue, and the 'correect fix' will be reworking the belt->inserter wake mechanic, increasing the overload inventory would only treat the symptom, not the cause.

I must respectfully disagree. My gripe is not that the inserter is slower or has lower throughput for belt <> container compared to container <> container, that adds additional pieces to the puzzle and makes some sort of sense since it needs to gather the items from a moving belt. What I dislike is that due to the trigger point the inserter can't achieve its full throughput and instead is idling some of the time even if the assembler could consume the input at full inserter speed. So, for me the trigger point is really the cause, not the symptom.

About expensive items: I can't think of any expensive input item where the throughput is so high you need to use stack inserters, and for normal inserters this won't increase the buffer that much. (and anyway, if the throughput approaches 10 items per second, you shouldn't care about buffering 10 more items as that is only 2 seconds worth of consumption...)

[ssilk]

My gripe is not that the inserter is slower or has lower throughput for belt <> container compared to container <> container, that adds additional pieces to the puzzle and makes some sort of sense since it needs to gather the items from a moving belt. What I dislike is that due to the trigger point the inserter can't achieve its full throughput and instead is idling some of the time even if the assembler could consume the input at full inserter speed.

I think we did understand the issue correctly.

So, for me the trigger point is really the cause, not the symptom.
About expensive items: I can't think of any expensive input item where the throughput is so high you need to use stack inserters, and for normal inserters this won't increase the buffer that much.

Think just to the rocket: It would be really a full fail, if the inserters put only 20% more in, of what's really needed. Say you need 2 hours for 100% you need then nearly half an hour more time. That is already a problem and your suggestion increases it, cause it is not only the rocket, but all other stuff, too.

(and anyway, if the throughput approaches 10 items per second, you shouldn't care about buffering 10 more items as that is only 2 seconds worth of consumption...)

Well, it's not, cause you multiply the problem with each step of production.

Many players oversee, that it makes much sense to have big buffers for resources and bulk items, but it is quite dangerous to have this kind of big buffers the steps above. It's then much more useful to have just-in-time-production and as less buffer as possible.

I recommend: Just wait, what they did change, and if it is still an issue complain again.

[Klonan]

My opinion about this suggestion: For expensive items this suggestion is a complete fail. Well, you can argue that the most players don't produce the expensive stuff in masses (and use stack inserter) but I think it should work in all cases. And this suggestion will not.

Yes, we discussed the issue, and the 'correect fix' will be reworking the belt->inserter wake mechanic, increasing the overload inventory would only treat the symptom, not the cause.

I must respectfully disagree. My gripe is not that the inserter is slower or has lower throughput for belt <> container compared to container <> container, that adds additional pieces to the puzzle and makes some sort of sense since it needs to gather the items from a moving belt. What I dislike is that due to the trigger point the inserter can't achieve its full throughput and instead is idling some of the time even if the assembler could consume the input at full inserter speed. So, for me the trigger point is really the cause, not the symptom.

About expensive items: I can't think of any expensive input item where the throughput is so high you need to use stack inserters, and for normal inserters this won't increase the buffer that much. (and anyway, if the throughput approaches 10 items per second, you shouldn't care about buffering 10 more items as that is only 2 seconds worth of consumption...)

I do not understand what you are disagreeing with,
The assembler wakes the inserter when it requires more items, increasing the overload multiplier will wake it sooner, this is right,
But this isn't the cause of it waking too late, the assembler wakes the inserter, but does not realise that it is taking from a belt, so that it requires more time.

Increasing the overload multiplier will fix it, but it is not the correct fix, if you further increase the stack bonus, the issue will reoccur at some point.