[0.15.23] inserter waits too long

[mrvn]

Time to add some save games with examples that are too slow.

[nljr]

The term "bug"...

Bug means different things to different people. The classic definition used by programmers is "a difference between the requirements and the implementation."

To get developers to take the other kind seriously, you have to say, "bug in the requirements". The less politic expression is "broken as designed"

[featherwinglove]

The real fix has to come from you devs to make inserter react sooner to emptying input buffers of such fast machines.

Can't we just get loaders in vanilla already?

Probably the best solution is to set the input buffer of the machine thusly. (This is pseudocode, as I haven't dug that deep into the original Lua ...probably not accessible in Lua at this point anyway.)

Code: Select all

# input_buffer = 2 * recipe.ingredient_count; <--- %^&# that.

input_buffer = (inserter.cycle_time() / machine.crafting_time() + 1) * recipe.ingredient_count;

# elsewhere, methods machine.crafting_time and inserter.cycle_time have been added.  It probably looks like

inserter.cycle_time{
  return 15; # or whatever number of updates it takes for the inserter to cycle
}

# In Bob's Inserters, it could wind up looking like this:

data::extend
inserter.cycle_time{
  # half the Bible
  if answer{
    return answer;
  }elseif{
    return 42;
  }
}

[Deadly-Bagel]

Assembly Machines scale their requirements when overclocking fast recipes:

viewtopic.php?f=6&t=37205&hilit=assembler+inserter

Assemblers already scale their overload multiplier based on the assembling machines speed

Just tested with a bunch of Copper Wire in a chest feeding two Assemblers via Stack Inserters. One Assembler was standard, the other equipped with 4 T3 Speed Modules. The faster Assembler needed 22.5 Copper Wire per second to fulfil its demand and was fed 24 Copper Wire, the normal Assembler required 9 Copper Wire per second and was fed 12.

Therefore your Inserters will ALWAYS have at least 1 second to react to the Assembler's requirements, plenty of time for Fast, Stack and their Filter variants to swing. The problem is that Fast Inserters may not move enough at a time, and Stack Inserters take too long to grab items off the belts. Therefore the solution would be *gasp* to use a Stack Inserter feeding from a buffer chest! If only someone had suggested it sooner oh wait.

This isn't a bug, it's a feature. Everything is working exactly as intended, just this particular relationship between belts, Stack Inserters and Assemblers doesn't meet high-profile requirements just as a single belt of Iron doesn't meet the requirements of an average base. The game is designed to challenge high-level play but you're complaining that the age-old belt-to-assembler tactic doesn't work for mega overclocked machines? Good! Find a way around it! That's the point of the game, no?

[Optera]

Assembly Machines scale their requirements when overclocking fast recipes:

viewtopic.php?f=6&t=37205&hilit=assembler+inserter

Assemblers already scale their overload multiplier based on the assembling machines speed

Just tested with a bunch of Copper Wire in a chest feeding two Assemblers via Stack Inserters. One Assembler was standard, the other equipped with 4 T3 Speed Modules. The faster Assembler needed 22.5 Copper Wire per second to fulfil its demand and was fed 24 Copper Wire, the normal Assembler required 9 Copper Wire per second and was fed 12.

Therefore your Inserters will ALWAYS have at least 1 second to react to the Assembler's requirements, plenty of time for Fast, Stack and their Filter variants to swing. The problem is that Fast Inserters may not move enough at a time, and Stack Inserters take too long to grab items off the belts. Therefore the solution would be *gasp* to use a Stack Inserter feeding from a buffer chest! If only someone had suggested it sooner oh wait.

This isn't a bug, it's a feature. Everything is working exactly as intended, just this particular relationship between belts, Stack Inserters and Assemblers doesn't meet high-profile requirements just as a single belt of Iron doesn't meet the requirements of an average base. The game is designed to challenge high-level play but you're complaining that the age-old belt-to-assembler tactic doesn't work for mega overclocked machines? Good! Find a way around it! That's the point of the game, no?

Yes after testing myself with the 0.16.33 it does indeed work from chest to assembler if the chest is filled fast enough. How to fill that chest fast enough with the space available in a fully beaconed setup is a mere design challenge.
I'll still use loaders to force feed such insane builds though.

[Nexarius]

the age-old belt-to-assembler tactic doesn't work for mega overclocked machines? Good! Find a way around it! That's the point of the game, no?

A assembling machine 3 without any modules and no beacon is a mega overclocked machine?
What would you call a assembler with 4 speed modules and beacons around it? A super ultra mega overclocked machine?

[Deadly-Bagel]

A assembling machine 3 without any modules and no beacon is a mega overclocked machine?
What would you call a assembler with 4 speed modules and beacons around it? A super ultra mega overclocked machine?

The fastest a vanilla Assembler can work without modules is 3 items per second, the most you would need to supply per craft is, what, 4 items for Electronic Circuit? So 12 items per second, Fast Inserters work at approximately twice per second (2.31 minus grab time) moving 3 items at max stack research, so at least 6 items per second per Inserter. Therefore 2 Inserters will grab roughly 12 items per second, just what you need for a 4-component 0.5s recipe in a 1.5x Assembler.

A single Express Transport Belt moves 40 items per second so you could feed 3 such Assemblers per belt with some throughput to spare. Of course in the case of Electronic Circuits, 9 of the components per second are Copper Wire so if using a single belt you could only (easily) feed two Assemblers. Using two belts is very tidy as you can have 3 lanes Copper Wire to 1 lane Iron Plate, which happens to be the ratio of the recipe! You could feed 6 Assemblers in this way with some throughput to spare.

So no, an Assembly Machine 3 without any modules is a regular Assembler that is more than capable of being belt-fed.

EDIT

How to fill that chest fast enough with the space available in a fully beaconed setup is a mere design challenge.
I'll still use loaders to force feed such insane builds though.

The original request was "This setup could feed my Assembler if the Inserters worked constantly", the problem being that Assemblers stop requesting items when they reach a threshold which is too low for Stack Inserters grabbing off belts. A chest will request items from the Stack Inserter as long as there is space so by the logic of the original request you could feed the chest directly from the belt.

[mrvn]

And then you have mods, for example Bob's mods:

Electronic Assembling Machine 3: Crafting speed 4
Tinned Copper wire: 0.5s, 3 Copper cable, 1 Tin Plate
That works out to 3 / 0.5 * 4 = 24 Copper cable per second. An inserter will stop at 6 and only has 0.25 seconds to refill.

Assembling Machine 6: Crafting speed 3.5
Roboport Antenna Array mk1: 0.2s, 2 Copper cable (and a lot of other stuff)
That works out to 2 / 0.2 * 3.5 = 35 Copper cable per second. An inserter will stop at 4 and only has 0.11 seconds to refill.

So, NO, this does not work as intended. At least not in mods. As said mods should be able to change the buffer factor to account for this.
Or the buffer factor needs to not only account for speed modules but for the base speed and time per cycle of the recipee as well.

Preferably both.

[Foreros]

My half cent (because 2 cents are too much) is: why dont let a variable instead a fixed value for the assembly machines?
Something like [2s/(speed production)] as a max amount of "buffer cycles" using the modified speed by modules and beacons let players have reduced problems from this.
If I use my 800% accelerated machine making copper wires, this give me a buffer high enough for let the machine work without any pause...
Just my though, I do not force anyone think that this is the perfect solution...

[urza99814]

I think this is perfect...if you're building the smallest/fastest/best of *anything* you have to worry about every single little variable. That's just how engineering works, and Factorio shouldn't be any different.

Quick example -- those of you who follow tech news probably saw recently that Samsung created a record-breaking 400GB microSD card. Biggest capacity ever in the smallest form available. But that 400GB number looks very suspicious -- flash memory chips are always powers of two, so you'd expect 256GB then 512GB. It's possible they put together a bunch of random smaller chips, but that doesn't make much sense -- 256 + 128 + 16? Why use a single 16GB chip?? I haven't seen this confirmed on denied, but the speculation is that it IS a 512GB chip...but they expect 100GB to fail or get corrupted, so they market it as 400GB. When you're building the most dense storage ever, *something* is going to go wrong, and they've gotta find some way to work around that.

In Factorio, we don't have those problems. We don't have to worry about data corruption from putting too many values in a combinator. We don't have to worry about bit flips from radiation. We don't have to worry about inserter arms crashing into each other if they aren't moving perfectly in sync. Instead, we get limitations like this. If you're just slowly smelting copper in a stone furnace, you just slap some parts down and it's fine. If you're making a 16GB SD card, just slap a chip on a board and ship it. But if you're trying to produce as fast or as dense as possible, you need to actually analyze every part of that system to make sure it's going to work. If you don't, you get unexpected failures.

[mrvn]

I think this is perfect...if you're building the smallest/fastest/best of *anything* you have to worry about every single little variable. That's just how engineering works, and Factorio shouldn't be any different.

Quick example -- those of you who follow tech news probably saw recently that Samsung created a record-breaking 400GB microSD card. Biggest capacity ever in the smallest form available. But that 400GB number looks very suspicious -- flash memory chips are always powers of two, so you'd expect 256GB then 512GB. It's possible they put together a bunch of random smaller chips, but that doesn't make much sense -- 256 + 128 + 16? Why use a single 16GB chip?? I haven't seen this confirmed on denied, but the speculation is that it IS a 512GB chip...but they expect 100GB to fail or get corrupted, so they market it as 400GB. When you're building the most dense storage ever, *something* is going to go wrong, and they've gotta find some way to work around that.

In Factorio, we don't have those problems. We don't have to worry about data corruption from putting too many values in a combinator. We don't have to worry about bit flips from radiation. We don't have to worry about inserter arms crashing into each other if they aren't moving perfectly in sync. Instead, we get limitations like this. If you're just slowly smelting copper in a stone furnace, you just slap some parts down and it's fine. If you're making a 16GB SD card, just slap a chip on a board and ship it. But if you're trying to produce as fast or as dense as possible, you need to actually analyze every part of that system to make sure it's going to work. If you don't, you get unexpected failures.

That is not what people complain about. They have analyzed the problem and found that there is no fix. No way to make it work.

[Foreros]

Easier idea, for samsung at least, is that they join a 128 and a 256 chip and they rounded up the number as done by HD creators. Find me a 2 TB disk that is really a 2 TB disk and not a 1,81 TB disk...
For the game, a simple variable can create few problems, but if planned carefully, (choosing parameter adequately) can be done in a relative safe way.

[urza99814]

That is not what people complain about. They have analyzed the problem and found that there is no fix. No way to make it work.

I don't see anyone claiming a circuit network setup is impossible; and buffer chests seems to still be under debate. Sounds like that isn't proven yet.

But even if it is, that still fits my analogy -- the 512gb chip just wasn't possible even though the parts exist.

Easier idea, for samsung at least, is that they join a 128 and a 256 chip and they rounded up the number as done by HD creators. Find me a 2 TB disk that is really a 2 TB disk and not a 1,81 TB disk...
For the game, a simple variable can create few problems, but if planned carefully, (choosing parameter adequately) can be done in a relative safe way.

That's not actually what's going on...that would just be fraud. The reason for that discrepancy isn't rounding, it's because the drive manufacturers use proper SI terabytes while the software is actually using tebibytes. Base 10 vs base 2.

[quyxkh]

I think the most important takeaway from this thread is that the title problem _doesn't actually happen_. OP shows his inserters waiting to pick up a large quantity from a slow belt before delivering. That's a setup problem: don't pick up a large quantity from a slow belt when response time's a problem. For a factory boosted high enough, no belt can be fast enough, you'll need buffer chests. But the game engine gives properly-supplied inserters plenty of lead time: it's not what's making them wait.

Max-boost A3

0eNq1mNty2yAQhl+lw7WVEQcd7Ls+QJ+gk8kgmThMJaECduPx+N0Lkqtk4lUkyPTKtgwf/7ILu6sLqpqj6LXsLNpdkKxVZ9Du5wUZeeh445/Zcy/QDkkrWrRBHW/9r0pwNxRdN0h2e/GKdvi6WZykVaV6pe27aeT6uEGis9JKMS48/Dg/dce2Etpxp9miEbXVsk5EJ/ThnDjJQj/zWrgFemUcwQlySztqQshDtkFn9w3Th+zqtX3gkntV9xicThgCY+iEMS1vmmQS2asGEobZjYchGgsTVcKasonSqIM01qmpX4SxibFK8wMkq7ipSiFeHs7LP+MV0fpKCFdG47YQbhttLYjDaTQPtBbjsBhhcIxgEr1rOcij0bwC5LHobYN5WTQPtvftUJhjZSwfJgKOoEuOmD0NvLbyJJJeq5Pcu6H38PJGBrnll7mw3m20o0GdJI3mwfc6jnY0zCPRPNheuipw2ELYELYK85YH5zhZ2HWSzmDyaC8SkBefIyjIK6O9CPPiswRoL00/VlZ387e3lOprJ1dVGf/Y9ELsk1btj41IqK+mIDZeZPtsMGoLhpNleBYNp8vwMhrOYkMMLGroF6oukPeFqgvkFbE82Nz49OJLhVnsdtnj40EIPwcsDbrqZvoGhmP9DFf80ekFxtGV90j4eWHvMo7l9S/Xfxmh7Sce9i7aS+0aouEvBkHfTg03RrRVI7tD0vL6RXZeyj167J+oQzuwHJtMrbrkILhO/rwI0aBPLANTMstXbloWvmmzp06L30f3CW4fHlZjg43DqKdn2bihY4P8r+GeyIP9fcOtD5ZaHX0rz8o0vT5Cisp4RfT/KNquDywy7cy7wMqhHjgNhdIVULz2dmLBkZKRtewinL0ij6YDuwxns2U2jWVny+w8lp0H1eFzr5GyIqwOHzmPo1pv1/T2bYMaXrnba4d+8NekUsrYb9/9DXhyx2wMScZIXtAiz9019hd05oYI

Build that gear factory (`/c game.player.insert{name="electric-energy-interface"}` to get an infinite-power supply in vanilla). Load up a bunch of iron plate with `/c game.player.selected.insert{name="iron-plate",count=10000}` and the mouse on a few likely-looking chests, drop a bunch of logistic robots in the roboports, do `/c game.speed=1/15` and look at what's in the assembler input buffer when the inserters trigger. On my 15.34 install there are 32 iron plates in the A3's input buffer when the inserters pick up a load. This is also true with my 14.23 install. The inserter is only waiting for things the player actually forced it to wait for, by telling it to collect a large quantity from a slow belt before delivering.

Switch the recipe to green circuits and four properly-supplied stack inserters is enough to keep a max-boost A3 operating at 100%.

[featherwinglove]

Yes after testing myself with the 0.16.33...

Whoa, I didn't think I hadn't logged into my forum account in that long

Assembly Machines scale their requirements when overclocking fast recipes:

viewtopic.php?f=6&t=37205&hilit=assembler+inserter

Assemblers already scale their overload multiplier based on the assembling machines speed

Just tested with a bunch of Copper Wire in a chest feeding two Assemblers via Stack Inserters. One Assembler was standard, the other equipped with 4 T3 Speed Modules. The faster Assembler needed 22.5 Copper Wire per second to fulfil its demand and was fed 24 Copper Wire, the normal Assembler required 9 Copper Wire per second and was fed 12.

Finally. The thing that I was missing that I've been asking for since close to OP time. Now...about mods? At least with Bob's we can do the reed inserter trick.

[mrvn]

That is not what people complain about. They have analyzed the problem and found that there is no fix. No way to make it work.

I don't see anyone claiming a circuit network setup is impossible; and buffer chests seems to still be under debate. Sounds like that isn't proven yet.

Go back to the begining: DaveMcW posted about chests not being enough, Optera mentioned Bobs inserters with the reduced rotation trick aren't enough and that buffer size doesn't grow fast enough with modules. Just recently I did some math for 2 recipes from Bobs.

As for the circuit network setup... It is probably possible and would idealy reduce the minimum time from 14 to 7 cycles. From looking at a few examples I think the minimum time with Bobs mods is 12 cycles without speed modules. But I only spot checked a few examples that I though were the fastest. I tried setting up such a circuit network but so far it always broke down when the output got backloged. Basically you have to start it full loaded and if it ever hickups the circuit network won't recover.

[quyxkh]

My best sustained green-circuit output from a single Bob's-mod A6 is 362/5sec, using nine perfectly-ordinary input inserters and three circuit-staggered unload inserters. The A6 never stops.

[DaveMcW]

I re-ran my tests in 0.15.34, stack inserters and chests do work properly now.

So the stack inserter and belt problem is unintuitive, but can be worked around.

[Deadly-Bagel]

And then you have mods, for example Bob's mods:

Electronic Assembling Machine 3: Crafting speed 4
Tinned Copper wire: 0.5s, 3 Copper cable, 1 Tin Plate
That works out to 3 / 0.5 * 4 = 24 Copper cable per second. An inserter will stop at 6 and only has 0.25 seconds to refill.

Assembling Machine 6: Crafting speed 3.5
Roboport Antenna Array mk1: 0.2s, 2 Copper cable (and a lot of other stuff)
That works out to 2 / 0.2 * 3.5 = 35 Copper cable per second. An inserter will stop at 4 and only has 0.11 seconds to refill.

So, NO, this does not work as intended. At least not in mods. As said mods should be able to change the buffer factor to account for this.
Or the buffer factor needs to not only account for speed modules but for the base speed and time per cycle of the recipee as well.

Preferably both.

Just confirmed this feature doesn't work for custom machines - Bob's Mods Electronic Assembling Machine for example only requests 2x recipe regardless, though not sure if it's because it's not vanilla Assembler or if it's because it doesn't have any Modules in it. Not sure how much control modders have over this but by default it should behave the same I think.

So yeah there's a problem in modded games.

[Engimage]

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