[0.15.23] inserter waits too long

[quyxkh]

If you set an assembler up with full input buffers and supply chests, empty output buffers and enough properly-staggered output inserters, set the game speed to 1/30, and watch what happens frame by frame, you can see that this problem doesn't exist: the loading inserters pick up a hand and deliver it well before the input buffers empty. It also doesn't exist in 14.23 (released April 2017), and the OP's complaint shows setup problem 1, not the claimed engine problem.

Idling assemblers are due to

1. inserters waiting to collect a full hand from a belt. Solution: load from a container, not a belt, so pickup's instant.

2. Insufficient throughput on the loading inserters. Solution: add more loading inserters for whatever ingredient is running dry. Max throughput on a stack inserter is (60/26)*12 ~ 27.69/sec.

3. Insufficient throughput on the unloading inserters. Solution: add to or circuit-stagger them, to manage (simplest case, eliminate) intervals with >=2 cycles' output buffered. (edit: updated for exactness)

It takes 9 free-running loading inserters and 3 circuit-staggered unload inserters to keep up with a max-rigged Bob's A6, effective crafting speed 36.6275, and simply not physically possible to pump enough items through a pure-S3 rig, crafting speed 35: 4 items * 70/sec = 280/sec, more than ten inserters just to load ingredients.

The problem with the Bob's electronics-A3's is it's 2×2, so you can only fit 8 inserters total.

[Kyralessa]

Speaking as a programmer, I know some of us find the word bug too whimsical and use the word defect instead, as it has a more uncompromising sound to it.

So is this a defect in the game?

No, it isn't.

The developers intended for things to go at certain speeds. If something in your factory isn't keeping up, it's not a defect in the game. It's a defect in your factory design. You need to find a different design that can keep up.

An assembly machine of any variety has no less than 12 entry/exit points. Why would you think you're only allowed to use one per ingredient?

[Deadly-Bagel]

The most simple task would be just add a resulting crafting speed as a multiplier to input buffer(as opposed to adding just % bonus from modules). This would solve the problem with custom machines (mostly).

That's also the stupidest solution. This might work for low-cost high-speed recipe but when it's the other way around you're going to get some ridiculous figures. A common example might be Roboports but a good example is Rocket Silos. The long craft times make a double recipe buffer more than enough, even with high craft speed, so simply saying "4x craft speed = 8x recipe buffer" is ridiculous. You would need to add some kind of check for the length of the recipe - if you're doing all this calculation anyway then why not just do it properly? 2x recipe buffer OR 1s components buffer, whichever is highest.

The problem with the Bob's electronics-A3's is it's 2×2, so you can only fit 8 inserters total.

A single Electronics Assembler 3 crafting TInned Copper wire, no modules, feed it Copper Wire with a single Stack Inserter from a chest. If you don't give it any Tin Plate you'll see the Copper Plate inserted is only a single stack, should be 2 (4 / 0.5 * 3 = 24). Set up another Stack Inserter feeding it Copper Wire and a third feeding it Tin Plate, the Copper Wire feed will occasionally pause as it hits its buffer but the craft speed doesn't allow the Inserters to react quickly enough, even from a chest, so the crafting will pause too if only for a moment.

[quyxkh]

Perhaps you forgot assemblers stop requesting input when there's two recipes' worth in the output buffers? That assembler's crafting speed 4, and that's a half-second recipe. You need more output inserters, because it's doing three or four recipes per inserter swing.

4×3×2=24 copper cable/sec, one input inserter's enough to keep up with the input demand.

edit: any time you find yourself making your case only by posting evidence that fits your view, you should start suspecting confirmation bias. That's what science teaches us: you have to forever be trying to imagine other explanations for what you're seeing. It's a simple question: "what has to be true in order for this to make sense?", and as long as you're asking it and rechecking your answers for blind spots, you're doing science. Your example shows the assembler demonstrably not requesting input. Your model offers an explanation for _why_ it's not requesting input, but you didn't exclude any other explanations.

[Foreros]

Now I'm using loaders because in vanilla game a fully functional copper wire assembly machine was too slow to load resources. I set EVERY TIME 3 inserter to load AND 3 to unload machine, but the machine has lot of "dead times" dued to the insufficient loading.
No, it was not a "too many finished products in the machine" because it was always a 0 items because all copper wires are removed in the exact moment they are ready, but there are missing copper plates for let the machine run.
Loaders have solved this for me because they push inside the machine enough resources for fill the ingredient slot, so there are ALWAYS resources for let the machine run.
I'm experimenting a stop only when, and only when, the output slot is full of copper wires.
In my factory this wont happen almost never, when I'm at full speed...

[Deadly-Bagel]

Perhaps you forgot assemblers stop requesting input when there's two recipes' worth in the output buffers? That assembler's crafting speed 4, and that's a half-second recipe. You need more output inserters, because it's doing three or four recipes per inserter swing.

4×3×2=24 copper cable/sec, one input inserter's enough to keep up with the input demand.

edit: any time you find yourself making your case only by posting evidence that fits your view, you should start suspecting confirmation bias. That's what science teaches us: you have to forever be trying to imagine other explanations for what you're seeing. It's a simple question: "what has to be true in order for this to make sense?", and as long as you're asking it and rechecking your answers for blind spots, you're doing science. Your example shows the assembler demonstrably not requesting input. Your model offers an explanation for _why_ it's not requesting input, but you didn't exclude any other explanations.

I had two Stack Inserters removing the finished product, PLUS a single Stack Inserter moves more than 8 items per second, and that doesn't explain why an otherwise empty Electronics Assembler only requested 12 or less (presumably 6) Copper Wire instead of 24.

So how about before getting smart and throwing around "confirmation bias" you make sure you aren't biased yourself? You literally ignored half the evidence I presented and made assumptions on the other half in order to have it fit your theory. How hilariously ironic.

[quyxkh]

I don't think I was ignoring the evidence backing the complaint, I think I was offering a correct explanation of that evidence.

Tinned-copper-wire recipe, ingredient consumption over ten minutes with 1 stack inserter loading each ingredient

Screenshot from 2017-09-13 06-57-34.jpg (10.04 KiB) Viewed 28283 times

Pretty picture of the design that does that

Screenshot from 2017-09-13 07-41-37.jpg (105.75 KiB) Viewed 28283 times

Blueprint of the design that does that

0eNq9lt2OmzAQhd/F17DCQMgWtTd9jK1WyMAkOyrYrjFRoyjv3gESkmxMNglSbxL57/N4zvHgHcurFrRBaVm6Y1go2bD01441uJai6vrsVgNLGVqomcekqLuWUbnSyli29xjKEv6ylO/fPQbSokUYGH1jm8m2zsHQhHF1pdbYWCz84gMa62vRNLgBXxu1wZKmekyrhjhKdgEQO/DYlqV+vN97V9hoNjZyYePZ2NCFXYzYxorit4+yAWNdlOhI8ViJBophKHEwk6lQDfxp6d9FD0/0w6xshRVNHaQ7ajqSLUpfV8ICoQrVdnYJg2D/7ghnOS6CisI2SmLR+LUoPlCCH13HEr8shmj4y6KPp0B92FNC6RdKazB+IfIKmGO/12tXXm3hH/cIaAsH49tstbkLy4O53MCJPenSXVgrpKUs1TlKYdWk2MGlk8JOSEnyVFkOH2KDtJKmn7vgqghs0NiWek4m7mf4b10dONiCn1eEvptU7PdsOhLvftYGQJ7XCCxpehcRmqJFO7RpufP04bh9SVYpO2/cOHw06n5x/Nh9/AMxo7ESx6BXaOiC3J0OIK8PGRnEoSCCrlVrYfogU/adFqnW6vYprN5mfbazlVF1hpIwLLWmhf2chIdnye7H+eeOpFc0nC9h9GgZ5F+XQR4/Xwf5vXXwohh9WQr5/eV+Md5Rly2PSR1t+YQr3y4tyZNPlvzBHnNPMiVucveh4/9+6JlnvvL3pwuymMrJcsqbDQUi1jBV/52PCP76MI3foM3++Dm/feHke09Qqm9SFzeo4dPU+AY1elIe59MxjJ+Uh2j0hu5f2unZw9xjlciB3M5+nvVtqEYNtTCOw2QZLZOE3sf/AHEPB+c=

This design was constructed according to that explanation of the considerations behind converting a non-working design into a working one. The explanation seemed clear to me at the time. On rereading it, it still does. Can you point out where it led you astray in your attempts to understand it?

[mrvn]

If you set an assembler up with full input buffers and supply chests, empty output buffers and enough properly-staggered output inserters, set the game speed to 1/30, and watch what happens frame by frame, you can see that this problem doesn't exist: the loading inserters pick up a hand and deliver it well before the input buffers empty. It also doesn't exist in 14.23 (released April 2017), and the OP's complaint shows setup problem 1, not the claimed engine problem.

Idling assemblers are due to

1. inserters waiting to collect a full hand from a belt. Solution: load from a container, not a belt, so pickup's instant.

2. Insufficient throughput on the loading inserters. Solution: add more loading inserters for whatever ingredient is running dry. Max throughput on a stack inserter is (60/26)*12 ~ 27.69/sec.

3. Insufficient throughput on the unloading inserters. Solution: add to or circuit-stagger them, to manage (simplest case, eliminate) intervals with >=2 cycles' output buffered. (edit: updated for exactness)

It takes 9 free-running loading inserters and 3 circuit-staggered unload inserters to keep up with a max-rigged Bob's A6, effective crafting speed 36.6275, and simply not physically possible to pump enough items through a pure-S3 rig, crafting speed 35: 4 items * 70/sec = 280/sec, more than ten inserters just to load ingredients.

The problem with the Bob's electronics-A3's is it's 2×2, so you can only fit 8 inserters total.

1. yes, belts are bad. chests are a must.

2. It's not the throughput that is the problem. It's the latency.

An inserter starts to pick up items when the assembler has less than 2 cycles worth of input. It takes 14 ticks to deliver the goods for a 180° turn. No matter how many inserters you add it will always take 14 ticks to deliver the goods. If 2 cycles take less than 14 ticks then the assembler will stall.

3. You can fit a lot more than 8 inserters to a 2x2 structure.

With vanilla you can put 2 rows of long inserters around the 2x2 structure for a total of 16 inserters. Although it you use chests then 8 stack inserters are probably better.

With Bobs inserters you can put 3 full rings of stack inserters around a 2x2 structure using diagonals too. So you can fit 48 stack inserters around the electronics-A3's. For maximum throughput they all should feed from chests so you need another (or two) ring of stack inserters and chests to spread the input buffer chests out so you can get enough belts to feed them fast enough. And then where will you put the speed beacons that makes this necessary?
Probably impractical without requester/provider chests.

Putting the maximum number of inserters around an assembler might not be the fastest though. Bobs inserters are faster the smaller the angle traveled is and way faster if they don't change length. So less might be more because you can place the buffer chests better to optimize speed.

[Deadly-Bagel]

I don't think I was ignoring the evidence backing the complaint, I think I was offering a correct explanation of that evidence.
...
The explanation seemed clear to me at the time. On rereading it, it still does. Can you point out where it led you astray in your attempts to understand it?

I see the problem, you're talking about a modded assembler, as in one that contains Speed Modules. You are correct that this works fine, however if you reread my post you'll see I specified an Electronics Assembler with no modules which does not work smoothly with its base crafting speed of 4. If you read back, we confirmed there was no problem when you installed modules but when using modded machines with a high base crafting speed and no modules, it doesn't work.

So while you are correct in your example, you missed an important fact that makes your example irrelevant.

[quyxkh]

If pictures and a working blueprint aren't enough, what would it take?

[featherwinglove]

I don't think I was ignoring the evidence backing the complaint, I think I was offering a correct explanation of that evidence.
...
The explanation seemed clear to me at the time. On rereading it, it still does. Can you point out where it led you astray in your attempts to understand it?

I see the problem, you're talking about a modded assembler, as in one that contains Speed Modules. You are correct that this works fine, however if you reread my post you'll see I specified an Electronics Assembler with no modules which does not work smoothly with its base crafting speed of 4. If you read back, we confirmed there was no problem when you installed modules but when using modded machines with a high base crafting speed and no modules, it doesn't work.

So while you are correct in your example, you missed an important fact that makes your example irrelevant.

Oh. So it really is still a bug. Just a smaller bug than we thought at first.

[Engimage]

To summarize this I see a couple of working solutions for this problem.

1. Add a moddable parameter to machines being a number of production cycles to store in input/output buffers. This would be great to have on all types of machines (furnaces included). With 0 being a full stack (unlimited). This is a way to avoid messing up with vanilla and let modders do it. I would personally get that mod right away
2. Make a machine crafting speed (including all bonuses) a multiplier to currently hardcoded 2 cycles. Not just speed bonus (as it is currently, probably) but a resulting crafting speed. So if a modded machine has a base speed of 4 it would compensate this by having a buffer for 8 craft cycles without modules applied.
3. Add a configurable value to machines that a user can manually set with default value of 2.

[Deadly-Bagel]

To summarize this I see a couple of working solutions for this problem.

1. Add a moddable parameter to machines being a number of production cycles to store in input/output buffers. This would be great to have on all types of machines (furnaces included). With 0 being a full stack (unlimited). This is a way to avoid messing up with vanilla and let modders do it. I would personally get that mod right away
2. Make a machine crafting speed (including all bonuses) a multiplier to currently hardcoded 2 cycles. Not just speed bonus (as it is currently, probably) but a resulting crafting speed. So if a modded machine has a base speed of 4 it would compensate this by having a buffer for 8 craft cycles without modules applied.
3. Add a configurable value to machines that a user can manually set with default value of 2.

1. This isn't a natural progression, it's like saying "we know there's a problem so here's a thing to fix it" - also how would it interact with modules?
2. You need to consider the length of the recipe, quite often in mods you'll have big items that need a lot of materials but a long time to build, if you just multiply recipe by craft speed by 2 you're going to end up with some stupid amounts of resources in your machines. Even non-modded, look at the Roboport, 10s craft time and requires 225 Copper Plate, 180 Iron Plate and 45 Steel. You start multiplying that by 8 and it's just silly, you're going to have almost 2,000 Copper Plate locked up in the machine - why?
4. Again this isn't really natural progression, the game is perfectly capable of calculating this stuff by itself so why should you need to mess about with it?

The best approach is to just fix up the existing calculations so it works without modules too.

[mrvn]

To summarize this I see a couple of working solutions for this problem.

1. Add a moddable parameter to machines being a number of production cycles to store in input/output buffers. This would be great to have on all types of machines (furnaces included). With 0 being a full stack (unlimited). This is a way to avoid messing up with vanilla and let modders do it. I would personally get that mod right away
2. Make a machine crafting speed (including all bonuses) a multiplier to currently hardcoded 2 cycles. Not just speed bonus (as it is currently, probably) but a resulting crafting speed. So if a modded machine has a base speed of 4 it would compensate this by having a buffer for 8 craft cycles without modules applied.
3. Add a configurable value to machines that a user can manually set with default value of 2.

1. This isn't a natural progression, it's like saying "we know there's a problem so here's a thing to fix it" - also how would it interact with modules?
2. You need to consider the length of the recipe, quite often in mods you'll have big items that need a lot of materials but a long time to build, if you just multiply recipe by craft speed by 2 you're going to end up with some stupid amounts of resources in your machines. Even non-modded, look at the Roboport, 10s craft time and requires 225 Copper Plate, 180 Iron Plate and 45 Steel. You start multiplying that by 8 and it's just silly, you're going to have almost 2,000 Copper Plate locked up in the machine - why?
4. Again this isn't really natural progression, the game is perfectly capable of calculating this stuff by itself so why should you need to mess about with it?

The best approach is to just fix up the existing calculations so it works without modules too.

I would say you have to divide speed by time. A speed 1 machine with 0.1s recepie has problems already. The resulting factor should be applied to the input and output buffer and and probably should be at least 2 cycles like it is now. Using cycles buffered = max(2, speed / time) would keep 0.5 second recepies with 2 cycles worth for speed 1 machines like they are now.

[quyxkh]

I don't think I was ignoring the evidence backing the complaint, I think I was offering a correct explanation of that evidence.
...
The explanation seemed clear to me at the time. On rereading it, it still does. Can you point out where it led you astray in your attempts to understand it?

I see the problem, you're talking about a modded assembler, as in one that contains Speed Modules. You are correct that this works fine, however if you reread my post you'll see I specified an Electronics Assembler with no modules which does not work smoothly with its base crafting speed of 4. If you read back, we confirmed there was no problem when you installed modules but when using modded machines with a high base crafting speed and no modules, it doesn't work.

So while you are correct in your example, you missed an important fact that makes your example irrelevant.

It's gotten impossible to tell whether the complaints are being continued as a conscious troll, as an in-joke for comedic-mockery-of-trolls value, or what, but it's verging on ceaselessly braying out nonsense. The post DB was replying to is essentially all screenshots and a blueprint of that exact setup ("I specified [A single Electronics Assembler 3 crafting TInned Copper wire, no modules] which does not work smoothly") working perfectly. "I see" above plainly doesn't bear any relation to its English meaning.

[Twinsen]

I didn't read through all this, but I changed how the maximum number of ingredients is calculated. Most of the cases of stack inserters waiting seemingly for no reason should be fixed since machines will accept more ingredients now.

For anyone interested here is the exact formula I used:

Code: Select all

  //1.166 is a magic number representing the maximum number of seconds it takes for a base game inserter to do one cycle.
  //the calculated overload multiplier is the number of crafts we can complete during one inserter full swing + 1
  return Math::clamp(uint32_t(std::ceil(1.166 / (recipeCraftingTime / craftingMachineCraftingSpeed))) + 1,
                     2,
                     100);

This will be in 0.16 unless some major flaws are found.

[posila]

Is craftingMachineCraftingSpeed value just from prototype or does it include also module bonuses?

[Twinsen]

It's the final crafting speed, including bonuses from modules and beacons.

[Engimage]

I didn't read through all this, but I changed how the maximum number of ingredients is calculated. Most of the cases of stack inserters waiting seemingly for no reason should be fixed since machines will accept more ingredients now.

For anyone interested here is the exact formula I used:

Code: Select all

  //1.166 is a magic number representing the maximum number of seconds it takes for a base game inserter to do one cycle.
  //the calculated overload multiplier is the number of crafts we can complete during one inserter full swing + 1
  return Math::clamp(uint32_t(std::ceil(1.166 / (recipeCraftingTime / craftingMachineCraftingSpeed))) + 1,
                     2,
                     100);

This will be in 0.16 unless some major flaws are found.

Thank you Twinsen you are awesome!
Again and again your team continues to impress by listening to players!

[featherwinglove]

This will be in 0.16 unless some major flaws are found.
...
It's the final crafting speed, including bonuses from modules and beacons.

Awesome! Three cheers for Twinsen: