Increase trigger point for inserting into machines

[BlakeMW]

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.

I don't get it.

And the current system is not a paragon of sanity, something like the satellite can buffer up to 200 low density structure - as the current input buffer is 2x the recipe requirements (1x to make the item, 1x as a buffer)

With the proposed scheme, it would instead buffer up 100 - the actual calculated buffer in accordance with inserter hand size would be 6/26, but obviously it needs to meet the recipe requirements.

Looks to me like the proposal is a big improvement as a recipe like the satellite wouldn't needlessly buffer up an extra 100 low density structure.

The only rare cases where more stuff is buffered needlessly would be expensive recipes which use 1 input (such as Rocket Control Unit), at present these will buffer up to 4 items when using fast inserters (once the buffer falls below 2, it inserts, this results in 4 items), with the proposed scheme it would instead buffer up to 6, with stacks it buffers up to 14, and with the proposal it would be 26.

Okay, back to the "I don't get it". Only in the rarest case does the proposal result in large buffers, normally it results in smaller buffers. Lets take the worst case, Rocket Control Unit, a slow recipe that will buffer up to 2 extra items in each input slot. A rocket requires 1000 Rocket Control Units, and if you're using 8 Assemblers then up to 16 extra processing units and speed module 1's could be buffered, assuming that you're producing processing units and sm1's precisely on ratio (if it's over-ratio the buffer is of no consequence) then this is a mere 1.6% of the rocket requirements. And in many cases, we're actually looking at smaller input buffers - for example a satellite can currently occupy 10% of the Low Density Structure, 5% of Rocket Fuel and 10% of the Processing Units costs of a Rocket in unusable buffer - you could have up to 50 Assemblers making RCU's before the new proposal results in more Processing Unit unavailability than the current scheme does.

[ssilk]

Well, this seems to be complex and with all that numbers here. Might be, that I misunderstood something.

So I try to understand and my picture about all those belts, inserters and assemblies is that as a number of bottlenecks and buffers. About like so:

Code: Select all

         BELT
           v
  BUFFER of one TILE
           v
       INSERTER
           v
    Inserter Stack BUFFER
           v
        Assembly (or whatever)
           v
     Input BUFFERS
           v
    Assembling time
           v
     Output BUFFERS
           v
          ...

So - and that is the point - your current task as player is to find the bottleneck. The right bottleneck!

And this is dependent on what you produce.

So instead of going now into the details and construct useless examples and throw around numbers, that nobody can follow I say simply: A solution of this has to think about every aspect of this queue I drawed above. Your suggestion does not think into to this and I won't argue, why it will not work better than yet, cause I'm sure if you think about it, you will see it yourself.

So I'm not saying, that I'm right, and you're wrong, I say: this is much more complex, than I want to think on a warm summer-day into.

[vanatteveldt]

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.

It's quite likely that I'm just really thick, but I don't think this is true. Suppose it takes an inserter 0.5s to gather material and insert to the assembler. Now assume that the assembler consumes exactly stack_size items per 0,5 seconds. So, the inserter wakes up when the assembler input < stack_size (+1, probably), and delivers stack_size materials 0.5 second later, by which time the buffer has 1 item left. If the assembler consumes more than that, then it is throughput limited and the inserter will work full time (so the trigger point is not the problem). If the assembler consumer less than that, the inserter can deliver on time (and there is no problem).

So, the solution scales with stack size, and the inserter will always be able to supply its full potential throughput assuming the assembler can consume it that quickly.

(of course, this doesn't solve the problem when you have multiple stack inserters inserting into a single machine, but that's a pretty extreme case given the throughput of a stack inserter)

[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.

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.

Compared to the complexity of the alternative, going this route would give the same result as putting a box between the belt and the assembler without the footprint space and with minimal complexity.

A single integer field will suffice- production queue size, currently it appears to be hard coded to 2. This is then multiplied by the number of each input to make an output to set the actual buffer size with minimal complexity. Should keep the amount of developer time to a minimum since it needs to be preserved in saves and blueprints as well as while running, and you are replacing what appears to be a constant with a user-configurable variable.

Would it be possible though to change the inserter behavior such that it always wakes up and delivers its full capacity even if the buffer is only 1 item below its target? Like so you would be letting the inserters fill above their target slightly, but would not require changes to the UI, blueprints, or saves. The only time this alone would not be enough to maintain inventory levels is a situation where the inserter takes longer to gather the necessary materials than it does to produce the item. And that situation is one that is only solved by using more than one inserter.