Loaders?

[Deadly-Bagel]

Pretty basic maths? You've got 80 Mining Drills most of which are boosted by each 8 Beacons and 3 Speed Modules for +550% speed. Each drill works at 0.525 items per second so with the speed boost that's 3.4125 items per second per drill. With 80 drills that gives you 273 ore per second total. To reach 805 you'd require +196% Mining Productivity, that's Mining Productivity 98 which requires 97,000 of each Science Pack (except Military), hardly a standard use-case.

The way to do this with belts would probably be to have more Mining Drills or even more Outposts - normally not an ideal solution however with that level of consumption you're going to be going through ore patches like crazy so I wouldn't call it an unreasonable alternative, covering more ore means it will last longer and you'll need to move the outpost(s) less often. And at that level of production you can hardly complain of cost.

[dood]

I've noticed that pretty much all loaders in the mods I have tried come in tiers of 3.
Why is that? Wouldn't it make more sense to have just 1 infinitely fast loader and if they are so powerful, make it post blue belts?

[impetus maximus]

I've noticed that pretty much all loaders in the mods I have tried come in tiers of 3.
Why is that? Wouldn't it make more sense to have just 1 infinitely fast loader and if they are so powerful, make it post blue belts?

well there is three tiers of belts. if we only had one, we wouldn't have cheaper versions that cost less material.
you don't need express belts/loaders everywhere.

[dood]

Do loaders need to be an early yellow belt thing tho?
Inserters are plenty fast enough to deal with those and there is not enough of a difference in speed between red and blue belts to justify 2 separate tools in my menu.

[Deadly-Bagel]

Can anyone answer why loaders would be a better than allowing 2x Stack Inserters to fully compress/consume a belt?

[McDuff]

I use (modded) loaders, but mainly for "inline" buffer storage. That makes for some better setups and layouts than inserters. I can also think of some interesting things you could do if you let inserter filters be circuit-programmable. I don't think that they either clutter up the menu or take away from inserters, but YMMV.

[Hedning1390]

Can anyone answer why loaders would be a better than allowing 2x Stack Inserters to fully compress/consume a belt?

Inserters have swing time and there's no getting around it, so they will never compress a full belt. But you could have 2 stack inserters fully compress a single line. This is already possible.

[dragontamer5788]

Can anyone answer why loaders would be a better than allowing 2x Stack Inserters to fully compress/consume a belt?

Inserters have swing time and there's no getting around it, so they will never compress a full belt. But you could have 2 stack inserters fully compress a single line. This is already possible.

I think he's trying to say that he wants this inserter-buff implemented: viewtopic.php?f=6&t=59074

Basically, kill the placement time of inserters, so that they would act more like loaders and more easily compress belts. Even with the swing-time, a stack-inserter moves 27+ items per second (chest-to-chest). The reason why chest-to-belt is so slow is because the inserter is forced to "wait" for the belt to move all the items.

[dood]

Can anyone answer why loaders would be better than allowing 2x Stack Inserters to fully compress/consume a belt?

It's the lowest effort solution if the devs can't change inserters that way because it is already in the game and just needs some polish.

[dragontamer5788]

Can anyone answer why loaders would be better than allowing 2x Stack Inserters to fully compress/consume a belt?

It's the lowest effort solution if the devs can't change inserters that way because it is already in the game and just needs some polish.

I agree. If loaders were added in say, "Logistics 4 research" or maybe "Loader Research" for late-game tech, then it'd be a nice addition to gameplay overall. It seems like one of the easiest "belt buffs" available to the devs. Its simply an issue of balancing the costs correctly. Something like 800x Yellow Science (and all lower tiers) would probably be an appropriate cost for loaders. My logic for 800x Yellow cost is that Inserter Bonus 7 is only 600x Yellow, and loaders are clearly far more powerful than inserters. Only express loaders need to be added into the game. Alternatively, maybe "lock" loader tech behind Inserter Bonus 7. (Want to load chests really quick? Well, max out inserters first, THEN we allow the upgrade to superior loader tech).

Loaders would upgrade belt->chest insertions from ~12 to 13 items/sec belt->chest, to providing an entity that provides 40 items/sec belt->chest. You'd be able to remove from a requester-chest at a rate of ~160 items/sec (interfacing bots with belts in a very simple pattern: 4 belts fed by 4-loaders unloading from the requester chest). Similarly, you'd be able to feed a provider chest at 160 items/sec (4 belts feeding 4-loaders feeding one chest). Finally, belt -> loader -> chest -> inserter -> assembly machine would take advantage of the 27 item/sec speeds available to chest-chest stack inserters. So its definitely powerful endgame-tech and it seems to solve a large number of issues that people have been complaining about in the endgame.

[bobucles]

Finally, belt -> loader -> chest -> inserter -> assembly machine would take advantage of the 27 item/sec speeds available to chest-chest stack inserters.

That's a lot of work just to double item input! Assemblers almost never struggle with grabbing enough items off a belt. Why is the loader needed when you can just use two stack inserters to get the desired input speed?

If an assembler is struggling to get items from a belt, the main issue is the belt doesn't have enough items in the first place. This can happen after a chain of 100 slow assemblers, 20 moderate assemblers or 3 very, very fast assemblers that max out the stack inserter's grab rate. In every situation a faster belt will satisfy more stack inserters, satisfy them more quickly, and allow more assemblers in the chain.

[Jap2.0]

4. To elaborate on point 3: bots may be able to be space-efficient in a small area, but they require more infastructure by way of roboports and power - especailly by way of solar panels and accumulators if you claim "power is free"
5. Bots require more resources to set up, including roboports, bots, power, chests, etc.

Resource expenditure doesn't matter if its dwarfed by more important resource expenditure.

Blue Belts use over 300% the resources of Red Belts but are only 33% faster. It seems like a bad choice at first, but honestly... we don't care and spam blue belts anyway, because modules and beacons dwarf the cost of infrastructure. Similarly, Bots (although more expensive than belts), are dwarfed by the cost of modules. Including the power-cost of beacon-boosted assembly machines.

If you're speed-running and care about resource expenditure of infrastructure to minute detail, then you'll want to stick with yellow belts as they're the most cost efficient. Alas, we're talking about Megabases. So all costs below a certain amount (everything aside from modules and science) are basically ignored.

By rocket launch 2000+, you really, really don't care much about even the cost of modules. Let alone the cost of all other infrastructure.

Your inital argument against belts was space. How are thousands of solar panels space efficient?

[dragontamer5788]

4. To elaborate on point 3: bots may be able to be space-efficient in a small area, but they require more infastructure by way of roboports and power - especailly by way of solar panels and accumulators if you claim "power is free"
5. Bots require more resources to set up, including roboports, bots, power, chests, etc.

Resource expenditure doesn't matter if its dwarfed by more important resource expenditure.

Blue Belts use over 300% the resources of Red Belts but are only 33% faster. It seems like a bad choice at first, but honestly... we don't care and spam blue belts anyway, because modules and beacons dwarf the cost of infrastructure. Similarly, Bots (although more expensive than belts), are dwarfed by the cost of modules. Including the power-cost of beacon-boosted assembly machines.

If you're speed-running and care about resource expenditure of infrastructure to minute detail, then you'll want to stick with yellow belts as they're the most cost efficient. Alas, we're talking about Megabases. So all costs below a certain amount (everything aside from modules and science) are basically ignored.

By rocket launch 2000+, you really, really don't care much about even the cost of modules. Let alone the cost of all other infrastructure.

Your inital argument against belts was space. How are thousands of solar panels space efficient?

Pretty simple. Some space is more important than other space. The miles and miles of space 2-minutes away on train that constitutes a solar farm is free from a UPS perspective and also free from a base-construction perspective. I don't even need to travel to my solar farm to increase solar production: you can place blueprints remotely these days. So as long as you have ample radar coverage, you can continue to grow solar farms automatically. Roboports can be included as part of your blueprint to automatically grow your logistic network + extend the solar farm very easily.

Base-space is very important: the smaller your builds, the quicker your concrete + exoskeleton legs can carry you through your base.

Bots (which take up a lot of solar space), effectively allow you to "outsource" space to locations far, far away. While belts take up valuable "inside my base" space, which increases walk times among other issues.

Finally, belt -> loader -> chest -> inserter -> assembly machine would take advantage of the 27 item/sec speeds available to chest-chest stack inserters.

That's a lot of work just to double item input! Assemblers almost never struggle with grabbing enough items off a belt.

That's certainly wrong! Wires are a particular issue for most players (although most stick to Wire -> Green Circuit direct insertion to avoid the issue).

But even Green Circuits themselves are an issue. 4x PM3 + 8x Speed Beacons means that a Green Circuit assembly machine produces 15.4 Green Circuits per second. Since inserter->belt is capped at ~12 items/second, your assembly machine output is broken.

HOWEVER, if you did Assembly Machine -> Inserter -> Chest -> Loader, you'd achieve the full 15.4 green circuit output. To be fair, I'm having difficulty visualizing how this would work with 8 beacons (there doesn't seem to be enough space). But under default settings, its difficult to build an 8x beacon belt-based AM3 without running into the ~12-items /second restriction that current stack inserters have.

[dood]

Finally, belt -> loader -> chest -> inserter -> assembly machine would take advantage of the 27 item/sec speeds available to chest-chest stack inserters.

That's a lot of work just to double item input!

Also you can just run a loader directly into an assembler.

[bobucles]

But under default settings, its difficult to build an 8x beacon belt-based AM3 without running into the ~12-items /second restriction that current stack inserters have.

It's even MORE difficult to build an 8x beacon belt-based AM3 without running into the 40 items/second restriction of belts.
Your beacon build breaks after the 4th assembler. Inserting faster makes it break after the 3rd or even 2nd assembler. In either situation the 8x beacon build struggles to be effective.

Beacon GCs are definitely one of the most demanding builds in the game, but many other things simply don't NEED that kind of extreme throughput. An 8x beacon engine factory can comfortably flow one belt to dozen assemblers and use regular or fast inserters to keep it happy. Most science types similarly only need 3-4 things to produce potions. Even at FTL speed a normal or fast inserter can keep them happy. Only high tech science needs a mountain of wires, but a single blue belt of wire can keep a few of those happy.

I'm not really a fan of doing all this niche tweaking just to fix beacon GCs. It's not like beacon GCs are the only things with throughput troubles. There are major throughput shortages with belt mining and belt smelting at the extreme late stages of Factorio. Late game mines transform into more belt than mine or players simply abandon it entirely for bot mining. Nearly every raw resource flows through a smelter somewhere so the sheer demand of moving items through smelters is even higher than GC beacons. Faster inserters only fix beacon GCs; you never need stack inserters to manage a furnace or mine. Making stack inserters even faster still leaves these other issues to suffer, which is why I don't like it.

[Jap2.0]

4. To elaborate on point 3: bots may be able to be space-efficient in a small area, but they require more infastructure by way of roboports and power - especailly by way of solar panels and accumulators if you claim "power is free"
5. Bots require more resources to set up, including roboports, bots, power, chests, etc.

Resource expenditure doesn't matter if its dwarfed by more important resource expenditure.

Blue Belts use over 300% the resources of Red Belts but are only 33% faster. It seems like a bad choice at first, but honestly... we don't care and spam blue belts anyway, because modules and beacons dwarf the cost of infrastructure. Similarly, Bots (although more expensive than belts), are dwarfed by the cost of modules. Including the power-cost of beacon-boosted assembly machines.

If you're speed-running and care about resource expenditure of infrastructure to minute detail, then you'll want to stick with yellow belts as they're the most cost efficient. Alas, we're talking about Megabases. So all costs below a certain amount (everything aside from modules and science) are basically ignored.

By rocket launch 2000+, you really, really don't care much about even the cost of modules. Let alone the cost of all other infrastructure.

Your inital argument against belts was space. How are thousands of solar panels space efficient?

Pretty simple. Some space is more important than other space. The miles and miles of space 2-minutes away on train that constitutes a solar farm is free from a UPS perspective and also free from a base-construction perspective. I don't even need to travel to my solar farm to increase solar production: you can place blueprints remotely these days. So as long as you have ample radar coverage, you can continue to grow solar farms automatically. Roboports can be included as part of your blueprint to automatically grow your logistic network + extend the solar farm very easily.

Base-space is very important: the smaller your builds, the quicker your concrete + exoskeleton legs can carry you through your base.

Bots (which take up a lot of solar space), effectively allow you to "outsource" space to locations far, far away. While belts take up valuable "inside my base" space, which increases walk times among other issues.

This is probably the point where it's subjective.
The thing is, we're talking about the space inside your base - and as an example, you provide a small bot outpost. That would be fairly small even with belts. Additionally, you have to consider the extra time it takes to set up mass production of bots, roboports, solar panels, and accumulators, as well as the time it takes to expand enough to build and protect your power supply.

[dood]

Additionally, you have to consider the extra time it takes to set up mass production of bots, roboports, solar panels, and accumulators, as well as the time it takes to expand enough to build and protect your power supply.

I don't think you should bring up time if balancing and individually spaghetti-ing 25+ belts is in play.

[mrvn]

You calculated I need 25 blue belts. Lets make that 24 green or purple belts so it is exactly one belt per train wagon. In Bobs each train car will carry 8000 iron ore per wagon (less in vanilla but that doesn't change anything). So each belt gets exactly 8000 iron ores unloaded. How can that ever unballance?

Okay, we're talking vanilla here so only blue belts. But even IF we were talking bob's, purple belts are only 5x Yellow Belts or 66.66 items/sec per wagon. The design I laid out can burst 110.8 items/sec per wagon (4x stack inserters chest -> wagon). So even 5x speed Purple Belts are something like 1/2 speed of the design I laid out. That's how much weaker belts are, even at 5x speed (compared to 3x speed of blue) they wouldn't be fast enough to keep up with the design.

Second: there are 6-wagons per train in the design. If one belt was "starved" of resources for some reason (ie: they were unbalanced), then the train would wait for the starved belt. This doesn't happen with bots, because bots have enough bandwidth to fully load all of the belts while load-balancing them.

This is seriously basic train design at this point. Have you ever built a megabase? Seriously? I'm surprised I have to explain the concept of belt balancers to you. The math is simple: if wagon#1 gets 20-items per second (from a 50% blue belt) while wagon#2 gets 40-items per second (a 100% blue belt), the train will take longer to load. In fact, it will take 100-seconds for the train to load. Wagon#2 loads up really quick, and then has to wait for wagon#1's much slower belt before the train can depart.

In the balanced case: if wagon#1 and wagon#2 BOTH get 30-items per second (75% "balanced" outputs), then the train will take 67 seconds to load.

You calculated I need 25 blue belts.

No. I didn't. But I'm tired of explaining things to you. So figure out your mistake here. I double-checked my words from earlier, and they're quite clear where 25-belts come from, and what they apply to. Figure out how many belts are needed per train. Its a simple division by 40 from the specified items per second: that's pretty basic math.

Note: The 25 belts thing was stating a fact. Not challenging your math. Dividing the specified items per second by 40 is math and doing math is called calculated. You calculated that number for me.

As for the balancing: You're assuming an end result that has no explanation. You start with saying your belts are already unbalanced. Then you say unbalanced belts will unbalance loading. DOH. You assumed the world is broken, ergo it's broken.

Why should the belt be unbalanced 50% to 100%? That would mean you have half the furnaces filling one belt compared to the other. Don't do that. Or you half the furnaces for one belt lack their input. I.e. the input belts are unbalanced.
Again, why would the input belts be unbalanced? If again you have one belt per wagon and since all wagons are the same size all input belts will be balanced. So all furnaces will run. So all output belts will be balanced. So the world is not broken. If you have multiple buffer chests or belts per wagon then you want to keep those balanced. But that is local to each wagon and requires a simple splitter or some circuit logic.

There is zero need for a full throughput 24 lane balancer. There might be some outside forces unbalancing the system, like the player taking 100 iron gear wheels out of a buffer chest. Such imbalances will be minor and as said a simple inserter setup between cars or lanes will balance that out. Not as fast as a 24 lane balancer would but we are talking about minor imbalances here compared with the throughput. Not trains coming in with one wagon half filled all the time.

[mrvn]

Additionally, you have to consider the extra time it takes to set up mass production of bots, roboports, solar panels, and accumulators, as well as the time it takes to expand enough to build and protect your power supply.

I don't think you should bring up time if balancing and individually spaghetti-ing 25+ belts is in play.

I'm not sure how you play but when I need a 25 belt iron gear wheel factory I first build a simple one lane version. Then I blueprint 23 more of them in parallel. Then connect outputs and inputs to the trains with. No belt crossing or spaghetti-ing involved.

[dood]

Again, why would the input belts be unbalanced?

Ore patches are not perfectly rectangular and run out you know.

Additionally, you have to consider the extra time it takes to set up mass production of bots, roboports, solar panels, and accumulators, as well as the time it takes to expand enough to build and protect your power supply.

I don't think you should bring up time if balancing and individually spaghetti-ing 25+ belts is in play.

I'm not sure how you play but when I need a 25 belt iron gear wheel factory I first build a simple one lane version. Then I blueprint 23 more of them in parallel. Then connect outputs and inputs to the trains with. No belt crossing or spaghetti-ing involved.

It's a bit more involved than just running belts into trains.
Unless you are okay with the train never leaving if one belt ran out of ore, that is.