Ultra-fast green belt with infinite research speedup

[Kyralessa]

Since many people favoring bots over belts point to throughput as an issue, how about improving belt throughput with a new belt tier?

Since yellow, red, and blue are used, this would be a green belt, which would be even faster than the blue belt.

Furthermore, it would include an infinite research item that would speed up the green belt a bit for each level of infinite research.

This could help level the playing field for anyone who'd prefer to use belts but for the speed issue.

[5thHorseman]

I'm not for adding 3 new parts, but I'm all for infinite belt speed research.

I think it should affect all 3 tiers.

[Zavian]

I actually think we want new mechanics along with a new hitech/lategame belt or belts that can help compete with bots in 8x8 beaconed arrangements. eg a belt that carries stacks of items, where each stack is between zero and stack_inserter pickup capacity (that way you could scale belt throughput by adding infinite stack inserter bonus research. Perhaps also with automatic alignment so you are never in a situation where a gap isn't big enough for an inserter to insert into. (If the graphics included trays or shallow boxes or dividers of some sort, that would 'explain' why inserters always insert into those trays.

[Ghoulish]

I actually think we want new mechanics along with a new hitech/lategame belt or belts that can help compete with bots in 8x8 beaconed arrangements.

Absolutely!

The belt-end-game so to speak does need a buff to keep it up with logistic bot set ups. The player should be better rewarded (with more equal performance) If belts are preferred over bots. It's easy to grid-up a bunch of assemblers with beacons if you use bots, but a lot more consideration is needed if you use belts.

Infinite belt research seems like one way to balance bots vs belts. But inserters would also need speed buffs too, think burner inserters trying to pick from express belts - just wont happen unless the belt backs up.

[bobingabout]

My logistic mod adds 2 new belt tiers.
it also adds 4 more bot tiers too though.

Also... Part of the reason why people think bots are overpowered isn't helped by the fact that you have research to improve bots, but NOTHING for belts!
So I'm all for research to help belts.

[steinio]

imho: faster belts need faster inserters to be able to grab sth.

[darkfrei]

IMHO all next tiers of belts must be twice faster than previous. Like yellow and red belt.

Upd
viewtopic.php?f=6&t=54465#p341022

[Drury]

The problem with belts in the lategame is that you're producing so many different items and you need a shitton of belts for random stuff like solar panels and walls, which don't even require a single yellow belts worth of throughput, yet to service those assemblers you have to sacrifice the space and time to put up a crappy belt going from copper and circuits and steel and stone bricks and other weird niche combinations. Faster belts don't solve that problem, robots do.

[Avezo]

Only if we get suggested log ago loaders/unloaders to work with such ultra fast belts. Can't imagine how ugly animations for inserters at ultra speeds would be.

And to be honest, instead of adding new type of belt, I'd turn blue one into this, it's already too expensive for what it's worth.

[hooiberg]

I like the idea of belt speed in the tech tree.

[Engimage]

There is currently no technical possibility to smoothly tune belt speed by research.
The way belts work is they "shift" items by discrete amount of slots per game tick (1 for yellow up to 3 for blue) and straight belt line is 32 slots long.
In this case you can only change the amount of slots item advances per tick. There can be no fraction.
The second problem is inserter speed. Fast inserters won't be able to catch items from the belt moving faster than factor of (5 maybe?) or so.
Given this mechanics you just can't implement infinite research for belts as they are. Ever.
Introducing a higher tier belt (like Bob's green one) is kinda helpful but won't change anything conceptually.

[Vegemeister]

There is currently no technical possibility to smoothly tune belt speed by research.
The way belts work is they "shift" items by discrete amount of slots per game tick (1 for yellow up to 3 for blue) and straight belt line is 32 slots long.
In this case you can only change the amount of slots item advances per tick. There can be no fraction.
The second problem is inserter speed. Fast inserters won't be able to catch items from the belt moving faster than factor of (5 maybe?) or so.
Given this mechanics you just can't implement infinite research for belts as they are. Ever.
Introducing a higher tier belt (like Bob's green one) is kinda helpful but won't change anything conceptually.

Fractions can be interpolated.

Have a floating-point accumulator variable. On each tick, accum += belt speed, advance the items on the belt by floor(accum) slots, and then accum -= floor(accum).

What this would look like, for a belt of speed 3.5, is that items would advance by 3 or 4 slots every other tick.

[bobucles]

Why bother using a floating point number just for a single decimal place? Floating points are headaches, just count the number of times 0.1 + 0.4 - 0.2 doesn't equal 0.3. It's dumb. Instead it's simpler to use an inflated integer scale- start at 10 and make subpixels less than 10. Of course if you want to dive into serious subpixel territory it's best to choose a large number that has a lot of divisors, like 65536. No typing, no need to deal with number conversions. Just a straight up integer representing every value that matters to the game, and no need to deal with the unlimited inconsistent floating point subpixels that don't.

I think unlimited belt speed is a bad idea for Factorio. Inserters start to develop serious issues when items fly by at a breakneck pace. The cool solution is for items to pack in higher, not faster.

Then make inserters faster lmao xd

I think that's a bad idea too. Inserters are fully capable of every important interaction between belts and assemblers. They don't need to be faster. The only place where inserters struggle is interacting between belts and trains. This causes train setups to rely heavily on large nests of inserters and chest buffers to smooth things out. I do think that the unimplemented loaders can find a purpose here for streamlining item transfer with trains.

[bobingabout]

Then make inserters faster lmao xd

I think that's a bad idea too. Inserters are fully capable of every important interaction between belts and assemblers. They don't need to be faster. The only place where inserters struggle is interacting between belts and trains. This causes train setups to rely heavily on large nests of inserters and chest buffers to smooth things out. I do think that the unimplemented loaders can find a purpose here for streamlining item transfer with trains.

try making an inserter (not fast, not long, the plain yellow one) grab items from an express belt, then tell me inserters are fast enough.
unless there's a backlog that causes the items to stop moving, the inserter can't grab them.
This is the kind of issue you'll have with faster belts, you'll need an inserter that can handle them.

[Aeternus]

The problem with belts in the lategame is that you're producing so many different items and you need a shitton of belts for random stuff like solar panels and walls, which don't even require a single yellow belts worth of throughput, yet to service those assemblers you have to sacrifice the space and time to put up a crappy belt going from copper and circuits and steel and stone bricks and other weird niche combinations. Faster belts don't solve that problem, robots do.

Technically, there's no reason you couldn't supply all the goods on a single belt. With some Combinator magic it's possible to dump the requirements for a single recipy on a single factory feeder belt. This adds complexity that most players won't enjoy, but its possible even in vanilla. It does require a trunkline for the rare resource (such as stone bricks)

Then make inserters faster lmao xd

I think that's a bad idea too. Inserters are fully capable of every important interaction between belts and assemblers. They don't need to be faster. The only place where inserters struggle is interacting between belts and trains. This causes train setups to rely heavily on large nests of inserters and chest buffers to smooth things out. I do think that the unimplemented loaders can find a purpose here for streamlining item transfer with trains.

try making an inserter (not fast, not long, the plain yellow one) grab items from an express belt, then tell me inserters are fast enough.
unless there's a backlog that causes the items to stop moving, the inserter can't grab them.
This is the kind of issue you'll have with faster belts, you'll need an inserter that can handle them.

Typically, the "ultrarawrmegafast" belts are used for bulk transfers, trunk lines. Not for directly feeding factories. Generally you'll want to split off some resources onto a slower belt to supply the buildings with. Unless it's a dead end (such as a railway loader station).

[darkfrei]

try making an inserter (not fast, not long, the plain yellow one) grab items from an express belt, then tell me inserters are fast enough.

Just don't take items from express and ultra express belts. Express must be splitted and you are use red or yellow belt by inserters.

[Zavian]

Then the these new belts don't address the use case of wanting to make green circuits between 2 rows of beacons. I can cope with the limitations of blue belts in most places, but I've never built a moduled and beaconed green circuit build that is a decent length, with a craft speed of 5.5.

[mrvn]

I too think that faster belts aren't the solution. For bulk transfer there are trains. So I think the long distance stuff is covered. Problem is the last mile to the assembler. And there there are too many issues with belt speed versus inserter speed and items flashing past the inserter before it can be picked up. And belts not getting compressed reducing the carrying capacity to less than 50%, worse the faster the belt is.

I think pallets or trays would be a better way to go.

Simplest case you have a pallet that holds 5 iron plates. (Infinite) research can increase that size. You can fit 5 times the iron plates on the belt and inserters pick up a whole pallet. And you get an extra puzzle piece by having to deal returning empty pallets.

For the end game I can think of a more complex pallet system though. Lets call those trays. A tray isn't simply a big heap of the same item but instead it would hold all items required for a recipe in the right ratios. Maybe even just for one cycle of the recipe. So one tray gives one output. So what have you gained? Now you need to assemble the trays and then assemble the finished product.

The way this should work is that you produce an empty tray (which you get back in the end) and then inserter can fill the tray bit by bit. So you build a tray for electronic circuit boards and send it to the iron smelter to pick up some iron plates. Then you send it to the copper wire assembler to pick up some copper wire. Last you send to it to the electronic circuit boards assembler to produce an electronic circuit board and an empty electronic circuit boards tray.

The benefit of this would be that you could put lots of different trays on the same belt for those millions of low throughput items you have in the endgame.

[Zavian]

I too think that faster belts aren't the solution. For bulk transfer there are trains. So I think the long distance stuff is covered. Problem is the last mile to the assembler. And there there are too many issues with belt speed versus inserter speed and items flashing past the inserter before it can be picked up. And belts not getting compressed reducing the carrying capacity to less than 50%, worse the faster the belt is.

I think pallets or trays would be a better way to go.

Simplest case you have a pallet that holds 5 iron plates. (Infinite) research can increase that size. You can fit 5 times the iron plates on the belt and inserters pick up a whole pallet. And you get an extra puzzle piece by having to deal returning empty pallets.

For the end game I can think of a more complex pallet system though. Lets call those trays. A tray isn't simply a big heap of the same item but instead it would hold all items required for a recipe in the right ratios. Maybe even just for one cycle of the recipe. So one tray gives one output. So what have you gained? Now you need to assemble the trays and then assemble the finished product.

The way this should work is that you produce an empty tray (which you get back in the end) and then inserter can fill the tray bit by bit. So you build a tray for electronic circuit boards and send it to the iron smelter to pick up some iron plates. Then you send it to the copper wire assembler to pick up some copper wire. Last you send to it to the electronic circuit boards assembler to produce an electronic circuit board and an empty electronic circuit boards tray.

The benefit of this would be that you could put lots of different trays on the same belt for those millions of low throughput items you have in the endgame.

Actually Deadlock made a couple of mods. One is a stacked items mod that (within the limits of what I expect is possible in lua) works pretty much how I hope the devs implement stacked belts. viewtopic.php?f=94&t=57264 . If the devs do implement stacked belts then I hope that the 'stacking box' could be removed, and that stack inserters could create stacked belts automatically, and that inserters could pick up stacked items and feed them to any machine. If they did that then that would solve the late game beaconed assembler throughput problem without needing faster belts or inserters.

Another is a boxing/palletting mod. viewtopic.php?f=94&t=57070 .