Factorio Forums

Also expose it to the API, so that you can set an entity to have a custom insertion limit.

Currently, it looks like it's being calculated relatively to the entity consumption rate, and as a multiple of the recipe source item requirement, say for example if you need 1 iron and 3 wires to make an electronic circuit at a rate of 3/s, the insertion limit is something like 3*1 for iron , and 3*3 for wires.

However, setting it to some arbitrarity low or high value (as a multiple of the recipe requirement count), or even zero, has many useful applications in terms of gameplay, and entity design.

Counter-intuitively, the manual insertion limit is actually much different, and looks to be relative to the stack size and consumption rate instead. Meaning for example what you can do manually, you cannot do using inserters.

+1
Being able to set a value X via input circuits for this multiplier, overriding the internal logic would be enough and very useful.

dupraz wrote: Fri Jul 10, 2026 5:52 am Currently, it looks like it's being calculated relatively to the entity consumption rate, and as a multiple of the recipe source item requirement, say for example if you need 1 iron and 3 wires to make an electronic circuit at a rate of 3/s, the insertion limit is something like 3*1 for iron , and 3*3 for wires.

For reference, this is the current insertion limit calculation.

dupraz wrote: Fri Jul 10, 2026 5:52 am However, setting it to some arbitrarity low or high value (as a multiple of the recipe requirement count), or even zero, has many useful applications in terms of gameplay, and entity design.

What applications?

Zijkhal wrote: Fri Jul 10, 2026 12:36 pm For reference, this is the current insertion limit calculation.

Looks like that besides some hard-coded exceptions, it's about exactly what I described, except it's for every recipes per 70 ticks instead of 60 ticks (per second).

Zijkhal wrote: Fri Jul 10, 2026 12:36 pm What applications?

Helps with buffering and tight production lanes.
For example, you would set it higher if you are in a situation where there is a sufficiently large discrepancy between the assembling time of a source item and the recipe itself, and your machines are synced to produce on the same tick (not staggered), without having to use chests (like for trains to some extent), since entities can already contain as much as a stack of items (or more) it's much more convenient.
Or being able to set it lower, one example is if you only ever need one source item at a time, and resume with a specific condition, because there machine consumes more than you'd like.
Finally, and the most useful example in my experience, if your machines are consuming from a tight belt, at the exact rate at which items flow, which is what space efficient designs should aim for, then having more buffering in the machine is actually detrimental, since it can induce a sort of logarithmic lag in the start-up of machines, where the first one in line initially consummes more than it really needs to, and can be really frustrating to witness when you are starting-up some part of your factory that isn't necessarily functionally steady-state, I think everyone who has witnessed this knows exactly what I'm referring to (usually you would need to manually disable your machine by selecting them for deconstruction, wait for belts to populate, start the machines, wait for a few swings, disable them again, repeat until they're full for every insertion limit beyond what's strictly necessary, etc.), and in fact speedrunners used to rely on some circuit hackery to circumvent this issue, but a regular option to achieve this smoothly would be really useful.
In short, a general logic for insertion limits can be frustrating to deal with when you want to micro-manage behavior, which is what circuit networks are supposed to help with.

dupraz wrote: Fri Jul 10, 2026 5:00 pm For example, you would set it higher if you are in a situation where there is a sufficiently large discrepancy between the assembling time of a source item and the recipe itself, and your machines are synced to produce on the same tick (not staggered), without having to use chests (like for trains to some extent), since entities can already contain as much as a stack of items (or more) it's much more convenient.

I am having a hard time picturing how the suggestion would help with this.

Either the source machine has a shorter crafting time, in which case the items get sufficiently buffered in the input of the next machine already, or the source machine has the longer crafting time, in which case it could only be an issue if the machine is crafting several items each cycle, and is somehow hitting output full conditions at times, starving the second machine? But isn't the trigger amount for output full related to the insertion limit, eliminating this issue?

dupraz wrote: Fri Jul 10, 2026 5:00 pm Or being able to set it lower, one example is if you only ever need one source item at a time, and resume with a specific condition, because there machine consumes more than you'd like.

This will have inputs inserted as the machine is working on a product, even if the insertion limit is reduced to x1 recipe. The machine consumes the ingredients from it's input the moment it starts a crafting cycle.

dupraz wrote: Fri Jul 10, 2026 5:00 pm Finally, and the most useful example in my experience, if your machines are consuming from a tight belt, at the exact rate at which items flow, which is what space efficient designs should aim for, then having more buffering in the machine is actually detrimental, since it can induce a sort of logarithmic lag in the start-up of machines, where the first one in line initially consummes more than it really needs to, and can be really frustrating to witness when you are starting-up some part of your factory that isn't necessarily functionally steady-state, I think everyone who has witnessed this knows exactly what I'm referring to (usually you would need to manually disable your machine by selecting them for deconstruction, wait for belts to populate, start the machines, wait for a few swings, disable them again, repeat until they're full for every insertion limit beyond what's strictly necessary, etc.), and in fact speedrunners used to rely on some circuit hackery to circumvent this issue, but a regular option to achieve this smoothly would be really useful.

Lowering insertion limit will not eliminate this, only alleviate it somewhat by shortening the startup time. The moment the machines start crafting, they will ask for more inputs, and the inserters will provide those inputs, even with x1 recipe insertion limit.

The only way I can think of to solve the startup issue is by clocking the inserters, even if you had the option to manage insertion limits by circuits.