Friday Facts #225 - Bots versus belts (part 2)

[deef0000dragon1]

I dont know if this has been mentioned yet, but what if the belts didnt automagically have jobs assigned to them? What if you had to specify that you want 10 bots moving items from point A to point B, stopping to charge at port C?

[ssilk]

...

Oh ssilk is still alive...

My interests shifted a bit and I have a new team at work, which does much more interesting stuff (React, Typescript, Redux)...
But sometimes I still take time to read a bit in the forums.

Well... yeah... seems like time doesn't stop and everything changes.

A lot of people from the past years aren't there anymore (except when lured out of their caves with controversial Friday Facts ).

But I guess that is what happens when a game reaches its final stage, only months away from being handed over to the hardcore modding community.

I think that quite natural: For the first 4 years Factorio was the most interesting game in my life. And in the moment, when it was clear that there will not be much changes anymore I rapidly lost interest.

But nontheless I would really like to see some of those old veterans somewhere in Prague (I guess they make also a release party when releasing 1.0).

[roman566]

Don't nerf bots. Enough said.

Honestly, the bots do what they were designed to do - allow megafactories. If you are going for rocket launch, bots aren't needed. Heck, for a speed run they are only a pointless resource sink.

But bots are boring! Seriously, at that point in game spamming belts left and right, setting up balancers, making sure you have enough space left 'in case dozen belts is not enough', adding more belts if it IS not enough, and so on, so on, is not boring. It's worse - annoying. At that point in time, player has won. Either it ends with a new game, or with a megabase. Laying thousands of belts for those bases is not very fun for me. Mostly because it's very hard to automate it. Bots, on the other hand, can be automated with ease. Need more X? Copy design where X is produced, paste it in some free space. That's automation and that is what Factorio is all about.

tl;dr

Bots allow players to automate large base creation. Don't nerf them. Players won't like it.

[deef0000dragon1]

That's funny, I might be wrong, but I get the feeling that most people who ask for a bot debuff actually mostly play without them (or with very little of them).
So basically, it's a "bots should be nerfed because I don't use them, so it won't change my playstyle, while hindering the pleasure of those who do like them".
I understand there are some extreme people who made 100% full bot megabases, and also people who did something close with belts only, but let's face it, these cases are surely a minority.
Most people happily mix both, and have fun with that. Nerfing bots will not make belts more enjoyable, and it's not a necessity.

I'd also like to point a comment made one week ago on another topic :

I think Twinsen has his head stuck in postgame land. He's seeing players finally reaching Factorio's breaking points in the post post post game, but treating it like a flaw in the main campaign. It's not. Players are reaching those breaking points because their objective is to literally break the game. The distance they have to go to reach those breaking points is nothing short of ridiculous, and the devs should be proud that players have to try so damn hard to finally break something. But step back and put things into perspective. Any balance discussion outside the game's main objective is literally, LITERALLY beyond the scope of Factorio. It's fun to see how far the post game can go, and if you have crazy new tools that help players to go even further beyond that's great. However, game balance in the post game is ultimately not that important. It's certainly not worth game sweeping changes that compromise the enjoyment of the main game.

This expresses very much how I feel about the idea of nerfing bots.

Now I'm very much in favor of making belts more fun. Not necessarily buffing them in terms of performance, but in term of flexibility and usability. What's been shown on the splitters is a perfect example of that.

I actually very much agree with this. While I would like loaders because they make belts more fun, I see no imbalance in bots as they are that can be solved without changing what bots do. Reason that I mentioned what I did a few posts up.
I would also not mind the literally stacked belts where its b1 above b2 above b3 mentioned around the quoted post as well.

[Maser]

I agree that bots should be nerfed. I love the design puzzle of using belts for fully beaconed setups, especially for complex end game designs. Using bots solves that puzzle instantly and makes the game so easy it almost feels like cheating.

For me, logistic bots shines in two scenarios:

1) uneven load systems, such as train stations or personal inventory refill
For this response time is very important, as well as being able to get the items you need with as few bots as possible. For this, speed is the most important but cargo size also helps to let you build fewer bots.

2) low quantity transports, especially in mid-game spaghetti factories.
For this overall throughput including battery charging times are important, but in the mid game you won't have significant upgrades yet and those makes a huge difference.

I think the best solution to all of this is to tweak charging times. For personal inventory refill, it would be enough if the bots could get the item and reach you in one charge, then it would be fine if they are stuck at the charging station for a long time. The same goes for train stations - as long as you have enough battery charge to unload the entire train the bots can rest until the next train arrives. This way you can "store" throughput and use it only when it's needed. Meanwhile, belts is constant throughput, higher over time but lower at the peak.

With that design, both belts and bots would have a niche - belts in constant throughput designs (such as 1k science per minute) and bots in uneven throughput designs (train stations) or for low to medium throughput very complex designs where you can't fit belts but requester chests would solve all your problems.

[SquarelyCircle]

For those responding to my comment about cost vs. output, I'd like to illustrate.

For the example, let's say it costs 10 input units to produce a bot, and each bot creates 10 output units per minute.
If you half the output of each bot, that means you are now producing 5 output units per minute, and you must produce 2 bots to reach the 10 output per minute that you previously had. This means that the cost of 10 output units per minute is now 20 input units, but ALSO that increases the CPU load, since the computer is calculating twice as many bots. If you were to increase the cost of an individual bot, you could still charge 20 input units and still get 10 output units per minute while maintaining the same CPU load. So, decreasing bot effectiveness is merely putting a tighter bottleneck on the CPU load, and really doesn't seem like the answer.

The irony is that people arguing against this point have made my point for me: if you increase the cost or decrease the output, you're not deterring anything at all. Players who want bots will still use them (cost is nothing, and therefore output rate is nothing), it'll just take more time to get there, and it will still be superior to belts, but (if you decrease individual bot output) will burn up your CPU.

That's why the solution to bots vs. belts is most definitely not a numeric nerf to bots. Buffs to late-game belts seem obvious at this point, and changes to bots need to be qualitative, not quantitative.

[bobucles]

Layered belts are a neat idea but introduces a whole slew of new problems. The main issue is how you control those belt layers. How do you move items up a layer or down a layer? Can you cross them? Can layers point different directions? How do inserters know where to take items or place items? Finally, how can you pack all that information into a one tile slot, with a finite number of pixels to show what's going on? Of course there are also the coding challenges involved in dealing with such a system. It all comes across as WAY too much. Players ultimately don't need an arbitrary pile of belts kicking around a single tile.

A previous poster showed a great little mockup of item stacking on belts.
https://webmshare.com/VGWYj

I'm surprised it doesn't get more love because it's a very simple and effective solution. It gives late game belts exactly what they need to compete with trains and bots: More throughput. The visuals are incredibly simple and obvious, I don't think anyone can look at this picture and be confused. There are a few coding challenges involved but we can simplify some things here. For example we can allow items to only stack with themselves. It reduces belt spaghetti and means you never have to guess what's underneath a thing. It also makes data storage relatively simple in coding terms- instead of belt item being a simple reference, it is that same reference and how tall the tower of items is. The only really complex question is how inserters deal with it.

I am of the personal opinion that ordinary inserters don't deal with item stacks. That is, they continue to output items in single file and prefer to grab items that way. There are many situations where stacking isn't important or even desired and you don't really need super belts for ordinary things. Stack output gets to be exclusive with stack inserters, which allow them to drop items in clumps of 3-8 (I like 4-5). This is great to unload from chests or trains where stack inserters get used in huge numbers.

Should stacked items push down a belt line and compress? Of course not. If items on top started sliding around it would cause a lot of confusion and would be an immediate disaster with sushi belts. Also it wouldn't be very intuitive because only the bottom item is on a moving surface, so items on top should stay put until something interacts with them. Players might attempt to max out all the stacks on their belt by dunking all the items on top, but we can still do one better by giving a new role to a currently disabled item. The loader would be an easy fit for dealing with max belt compression, allowing a dedicated solution to collect a messy input and dish out the maximum possible items on a belt. That makes it a natural fit for train stations and chest buffers.

Item stacking creates a new type of belt puzzle for players. They have to learn anew how to stack their belts and get the most out of them, while lacking the flexibility of creating stacks with long inserters. But limiting options can be even more fun than giving everything straight up. Pumping a belt up with 4 or 5 times more output will definitely give them what they need to deal with beacon builds and high tier ore mining, and compressing entities might even save some UPS. I can't really predict much beyond that.

PS: Item stacking can also help out a bit with chest explosions by letting items stack taller instead of spiraling out a dozen tiles. It leaves fewer total entities on the field, which might be a good thing. You could even get crazy and create speed penalties for trying to wade through ridiculously tall stacks of junk on the floor.

[stretch611]

Factorio is not a competetive game. It is a sanbox game. It is fine stuff is not well balanced.

LOL! I'm saw that opinion a few times in this thread. It is basically like writing "Factorio is a sandbox game so is it fine if it sucks." - just a few levels down.
No, the game should be well-balanced. It will ensure that it will create an interesting challenge and be fun to play. It doesn't mean that it won't allow different play-styles, thought.

I'm understand where these opinions come from. We are afraid that the play-style that we are used to will be no longer possible or that are current factory will cease to work. To be honest, I am afraid of that too.
However, we have to remember that this is still early-access game and there will be changes. It isn't finished yet; it isn't fully balanced, and you can't do that without changing anything. So, if these changes brings more positive consequences than negative, we have to sacrifice some of our comfort zone and accept that. This will eventually come in our favor.

Well said.

So far in the 20+ pages I have read, and the 46 pages from last week, There are a few that are insulted that the devs are even considering nerfing bots.

I get it... No one wants to play a game only to find out that the solution they have been using for hours is going to be changed for the worse. While I personally use a a big release to start clean I know some players have invested hundreds of hours over multiple releases. Its hard to see your work marginalized.

As mentioned, this is Early Access. It is to be expected; especially with a system that is overpowered compared to others, and yes, IMO bots are overpowered compared to other logistic methods.

Some of you are complaining that they are taking away your freedom... all before any comment on exactly what will be changing. If you think bots are going away, IMO you are severely overreacting... they said that wouldn't happen and there is no reason not to believe them.

Some are saying that the devs are forcing a single way of playing on the player base. WRONG... combined with a future buff to belts they are allowing something other then belts to be an alternative. Right now, for the highest throughput, the only choice is bots... we have a single high throughput way now, a bot nerf combined with a belt buff will allow us to choose either giving us multiple choices. As Kovarex specifically said:

Players would still be able to build robot only factory, belt only factory or combination of those, but the strongest strategy would be to combine all types of transport, each for the part where they are the strongest.

Some have even said that the devs are not even listening to their players... Wow!, that is wrong on so many levels. The forums here are proof that they do listen. The FFF even encourages feedback. We all know the chances of even getting a response from big publishers... nil; they may push out updates without any notice with game changing patches that make any possible nerf here seem minor. And how many times do they add new things in a DLC that they force you to buy, while removing functionality at the same time. Even a bunch of indie devs on steam only write every now and then only to announce a new release and not even acknowledge any responses.

Be happy... the devs here obviously are trying to put out the best product they can. They are actually doing it quite well too. Yes, balancing is a necessary part of that too... even when it is not universally accepted.

[BHakluyt]

That stack mockup pic above is awesome. Never thought of that. How about mk4 (see my posts on pg 26.) belts have the ability to stack too. Start at simple 2 high stack default and expand with more rocket research.

In essence this whole mk 4 thing is a late late game bundle.advanced stack inserters/heavy duty inserters can place items in stacks and can lift packaged heavy boxes. Whatever gamers and devs fancy most in the end. So we have mk 4 belt, ug, splits, assembler, mk2 stack onserter. Oooh make this mk4 belt stuff require electricity too.

Come on, I did not spend all weekend in a sleep deprived factorio delusioned mind wrapped in this stuff 24/7 for nothing. Use it. Do it. Thats the answer. Leave bots as is. Maybe even add some of those suggested improvements. Some nerf could be cool too like aue and delay at provider chests...

Either way, add this 4th tech please. Thats what I would have done if I was starnded on this planet and had to figure sht out for myself and make a plan.

[Ramblin]

Like many - this is my first post on this forum.

Meta Discussion

First, a couple things I'd like to say that are somewhat "off" topic, but motivated by the threads from the last two FFFs:

1. I'm super impressed with Factorio and the interactions of the development team with the community. This is my first early access game and won't be my last.
2. I'm impressed with the number of folks who have pretty darn good written English when it obviously isn't their first language. My attempts to learn non-programming languages have been a failure.
3. Some of us in the community need to Calm Down. Yes, I know this is the Internet (and yes this isn't a new problem, I've been on electronic discussions like this since 1982). Part of this is remembering that, unless you work for Wube, this is just a game. That said, it's a good game and we care (and I get that). Whatever the reason - you don't need to take it so personally!
4. The dev team has responsibilities that the rest of us don't share to create a game that is fun for players who aren't yet part of the community. That said, I think the responsiveness which the devs have shown to community input has actually been fairly awesome and has made the game better.

High-Level Comments

A number of high-level things have occurred to me while reading this weeks thread in full (I didn't have time last week). I think the one thing we've proven in this discussion is that different people find that different things are fun. For some, it's the logic of routing the belts and the resulting aesthetics. For some it's pushing the limits on how much Science they can make/how many rockets they can launch/etc.

Sometimes I think it helps to understand a poster's background to evaluate their comments - so quickly about me: I've been playing almost 2 years - but only have 1219 hours in. Real life interferes with my gaming. I've not ever built a mega-base. Actually, there is a "zen" feel to the early game that I really like - sometimes I'll fire up a new map just for the sake of playing around without having to think too much. I've done several bot-heavy and belt-heavy things within my more limited bases. I've run into some of the challenges of bots (like my train unloading bots caused interesting power problems at one point) so I can imagine that bot-based mega-bases aren't as easy as some people think.

I do like the flexibility of bots for some things, like if I'm making an item right after I got the tech and I haven't figured out how I want to do the "fullscale" production. I haven't gotten into the dense beacon-based mega-production areas where belts "aren't an option".

More "On Topic" Comments

There are a few of the comments folks have made really struck me as important in my own thinking about this:

1. To think about the balance between elements I think it is important to think about the whole "lifecycle". Bots have a lot of up front costs in the research and operational costs (power) which belts don't share. In many ways that makes sense of the expanded capabilities.
2. It seems like the biggest issues with belts are:
   1. The space they take (especially important in beacon-based production)
   2. The "bandwidth" of belts
   3. The "bandwidth" of getting things between entities (basically inserter bandwidth)
   4. They seem to max out on their usefulness too early in a way that makes bots seem overpowered.

For myself I like the ideas to add some more capabilities to belts such as loaders, palettes, etc. I really like the new splitter options - I wouldn't mind seeing some more "programmability" in the belt system, either through additional capabilities like this or new circuit network "controls". I also think more flexibility with the inserters (like Bobs Inserters) are very worth considering. I'm not sure that seriously nerfing bots is the right answer. Whether there are some minor balance things to be done with bots is an open question.

I also think bots could be more interesting with some QoL improvements of their own. For me the bots sometime leave me wanting to control things better. I'll do things like leaving spaces in between logistics areas so that I can contain the flow of bots, but it'd be nice to do that with controls within the logistics network. So I'd welcome some things that give additional control - for example logistics subnets. I'm looking to getting to the point where I get to try out the new buffer chests to "manage" the flow of products within a logistics area better.

For that matter - I'd like to see some additional control in Trains - like the ability to really route trains based on circuit network input!

I'm also for putting some of this "smarts" behind additional research and for putting them into the circuit network interfaces with devices.

Sorry that this has rambled, but hopefully it adds to the discussion.

EDIT: Fixed a grammar error - and an additional comment:

Anything that gets suggested in the forums is all well and good - but it has to be implementable, with decent enough performance, within the staffing constraints of the development teams. While we can be unrealistic in the game, we can't be unrealistic about the game.

[vipm23]

S2: Worth testing, but I predict that this will just be overgone by the players with more chests, which is a backstep.

The current situation is that bots have an infinite maximum throughput per tile, which no other means of transport has.

If a queuing system is added, bots would be limited to a finite maximum throughput per chest, which means that even if a player plops down more chests he will never get infinite maximum throughput per system. S/he will only get a linear increase in throughput in the system as s/he places down chests, same as if s/he had placed down belts.

[anarcobra]

WRONG... combined with a future buff to belts they are allowing something other then belts to be an alternative.

Unless they improve belts to the point that it's possible to have the same or better performance as bots do now then they are not giving any alternative, only taking the current one away. Unless you don't think that making the maximum buildable factory with reasonable UPS smaller is not taking something away. At some point one of the devs said they want more belts in megabases, so players watching youtube etc will see more belts. But what's the point of building yet another megabase if you already know at the start that it's going to be half as big (in throughput) as the last one you built purely due to performance reasons? The only reason I can think of is some other added constraint such as a mod, or some new feature the base game adds that I haven't heard about yet. And even in that case, what would be the incentive for a megabase builder to update? Wouldn't he just build his base in the old version where he can have whatever constraint makes that build unique plus being able to build big due to bots?

The problem here is that nerfing bots isn't just an ingame ballance thing. For technical reasons that have nothing to do with game design, bots allow you to build bigger factories than belts. As long as this remains the case, megabases will use bots. Nerfing bots in a way that cannot be countered by simply adding more would simply result in smaller bases, unless belts are improved to make up for that. I don't know what the status is with all the latest belt optimizations, but as far as I know bots are still more UPS friendly. It's the same reason megabases use solar and not nuclear.

All the other benefits of bots are nice and all, but for a megabase don't really matter in the end. So what is the purpose of a bot nerf? Is it to affect megabase builders? They are probably a tiny percent of the player base. Is it to affect casual players? If then answer is casual players and we don't care that the max factory is a bit smaller, then yes a nerf might work. If the answer is megabase builders, then I don't see how making megabase building worse in the game is the solution.

[bobucles]

The current situation is that bots have an infinite maximum throughput per tile, which no other means of transport has.

But that is not true. While a mountain of bots can deliver a huge amount of items at once, that value is equivalent to the concept of "burst damage" in an RPG. A pile of bots can finish a job in a hurry, but on the back end you have a completely useless system for several minutes as they charge back up. True sustained throughput is limited by robot charging bays, and they take up a healthy chunk of real estate.

[vipm23]

The current situation is that bots have an infinite maximum throughput per tile, which no other means of transport has.

But that is not true. While a mountain of bots can deliver a huge amount of items at once, that value is equivalent to the concept of "burst damage" in an RPG. A pile of bots can finish a job in a hurry, but on the back end you have a completely useless system for several minutes as they charge back up. True sustained throughput is limited by robot charging bays, and they take up a healthy chunk of real estate.

True, but consider:
1. Robot charging bays don't need to be near the chest being interacted with, so you can use any piece of real estate you own to house charging bays.(Compare this to belts, which can't use just any tile, they have to have an uninterrupted path from point A to point B.)
2.The only cost to real estate is clearing the biters off, which is payed only once, and securing it against attack, which drops in cost per tile as you expand because the ratio of perimeter-to-area decreases.
3.You can achieve an arbitrarily high throughput per container by placing more charging bays and bots down, without otherwise improving the system.

[MrNycon]

I think the bot OP issue could be solved by fixing another issue with the game that bothers me - power distribution. Right now you can hook up a nuclear power plant with a single small electric pole and provide power to an entire megabase. Much like how belts have a maximum capacity and throughput, so should power poles. This would force players to improve infrastructure to increase bot usage, not just plop down another blueprint. It would also add another layer of building to the game.

[Ramblin]

One other QoL item I'd like to suggest for belts: something along the ghost planner for rails. I think that's been mentioned, but I wanted to add my +1.

[GenBOOM]

when i read stacked belts ... i actually thought about something like this

this would be fantastic

indeed

Imagine building belts in layers from ground level and then -1 -2 -3 +1 +2 +3 with some kind of easy way of changing between the layers/views!



Regarding bots, Its a flying intelligent thing, it makes sense it can do amazing things, but maybe the resource cost or resource upkeep of bots is to low compared to the throughput given. I mean how does the power efficiency look like between bots and belts? If bots have 5x the throughput of belts and more flexibility then maybe the power usage can reflect that.


Another suggestion is to introduce assembly-kits - that cannot be transported by bots due their to size and weight. A kit is a prepackaged box/pallet with all needed resources in the right ratios for a given recipe. The kit increases assembly speed as the kit is pre-organized, increases delivery throughput to assembler as it is one box with all resources in the right ratio.

when I first mentioned layered belts, this was the thing I was actually talking about, not stacked belts.
this would make belts more space efficient but the most complex and interesting thing to work with.

the challenge is making it work visually since each belt has 2 sides, building up will hide 1 side of the belt.
maybe with showing the side of the belt visible to the player and then a light indicator on the side of the layered belt for the hidden side of the belt? 1-6 lights for each tile, but requires power.
with this you can layer up as high as you want and powering the lights is optional

your assembly kit gives me the idea of robots being able to directly interact with assemblers (at the current access speed), rather than chests (nerf chest access to be in line with red/blue belts)
so in this situation to utilize bots properly requires a massive assembly block where bots can take from a line of assemblers and deliver to another line.
this also means that things requiring basic plates must be supplied with belts and inserters rather than bots
for example copper wire must be supplied copper via belt/train rather than bots but the bots can then take the output of the assembler to another assembly line, like green/red circuits
this would lead to building your assembly in chunks from start to finish for each end product.

with this it would require all 3 techs to make your mega base assembly and bots would still give you a production boost but those that use bots just for blueprint building and the occasional order will not really notice the change.
the idea is that bots should be used for constant production, and storing production should be left to belts and trains have the job of transporting that storage

[Inverness]

An interesting sci-fi idea I saw was converting materials to liquid that could be pumped throughout the factory instead.

My elaboration on this is basically dematerializing anything on a belt into a stream of matter that can travel through a special kind of pipe until it reaches a rematerializer which turns it back into whatever went into it. The dematerializer and rematerializer would have significant power draws, but not the pipes. The benefit over belts would be that would be that the pipes could transport at least 10x the material that the equivalent belt could. Feed 16 belts of iron into 16 dematerializers that feed into a single pipe. The sci-fi aspect of all of this means that any material that can be placed on a belt could be used like this. You could even have train carts for it. Filtering can be used to get only the item you want from the matter stream. In other words it would be safe to mix different materials into the matter stream.

The nature of the system means that transportation through the pipes would either be instantaneous or very, very fast. From the programming perspective, you would treat all attached matter pipes as one entity that contains X amount of a particular item. In order to make this work while still having a concept of maximum throughput you would have to disallow any sort of basic 3 or 4 way intersection with this kind of pipe without a special kind of object. This object would allow you to hook up 4 pipes to the four ends and select what kind of material goes in which direction. Other than that, you would only be able to use dematerializers and rematerializers to add and remove matter from the matter stream.

It's not belts but it's a high level alternative to bots.

Another idea I had was to make layered belts possible without breaking many other things: have the second layer be below the normal layer instead of above it. You would basically have a double layer belt going through a trench.

This could be expressed by the art in two ways. The first is to add a tile border effect around the belt tiles to visually separate them from the normal belts. This would be a yellow and black (belt-color and black) warning stripe design a few pixels wide that would appear in the adjacent tile. This would only be visible if there are no adjacent belts, so the second art change is to change the shape of the arrow that appears on top of the belts. Perhaps two arrows one in front of the other like ">>". This would make it easy to identify a double layered belt even if objects place adjacently are hiding the warning stripe effect.

Of course the big question is how would you underact with this second layer. I would suggest that all things that currently interact with belts only interact with the top layer. You would have to use a new belt part called a swapper that exchanges the bottom layer and the top layer.

The two big downsides to this approach is that you can't see the contents of the bottom layer, and it's only a doubling of the belt capacity.

[m44v]

(...)
A previous poster showed a great little mockup of item stacking on belts.
https://webmshare.com/VGWYj

I'm surprised it doesn't get more love because it's a very simple and effective solution. It gives late game belts exactly what they need to compete with trains and bots: More throughput. The visuals are incredibly simple and obvious, I don't think anyone can look at this picture and be confused. (...)

Yes, but with iron plates, an object that looks mostly flat. I bet it wouldn't look so neat and clear with items that aren't square and flat, like ores, batteries or science flasks.

[DaemosDaen]

This was written at page 27, and to be honest I'm not gonna go back through it all.

In your test, you missing the bot charging data because you don't have enough bot charging points for that cloud.

The ONLY reason bots are heavily used for larger bases is because of the lag belts have. The lag is caused by the number of items on the belts. the easiest solution would be to lower the number of items calculated on the belts. You have 2 suggestions above. I'm not a big fan of the crating/pallet idea in the form it's given, mainly because it clutters the crafting menu and it has to be set. If there could be a machine set up like a furnace where it auto sets the recipe based on what is inserted it would be better.

------

My personal idea would be Compressed Express Belts: We'll call it the Pink belt for the moment.

You need to have completed the last stack inserter bonus as well as the ability to launch a rocket as this is a white science.
4000/30 seconds sounds about right.

How it should work:

The belt would carry items in stacks of 12, thus why the stack inserter bonus would need to be completed to get these belts. They come with the standard addons; undergrounds and splitters and move as fast as an express belt and only renders a single item, not items stacked, rendering items stacks may look cool, but causes other issues:

Inserter interaction: Only interacts with stack inserter, Stacks inserter pick up one compressed item off the Pink belt and placed the 12 items into the machine directly. You COULD put the 12 items on a yellow, red or blue belt (from here on out called "normal belts"), but you don't want to do that. (see splitter)

But you don't want to have to go around ripping up your base to put in the new belts, do you? Me either. Some of my builds only need like a yellow belt's worth of materials. The splitter is where the magic happens: The splitter would change how it works based on what it detects on the input and output sides, examples:

Splitter logic:---

Pink belts on both the input and output sides the Pink splitter: this acts like a normal belt, except for compressed items on the belt.

Normal belt on the input side of the Pink Splitter: that side of the splitter gets 2 - 12 item buffers (one for each lane of that side of the splitter) if you have normal belts behind both sides of the splitter, it would have 4 - 12 item buffers. Once the buffer is full, it sends it along to the front side.

Normal belt on the output side: 2 - 12 item buffer is created similar to the input side, however this one simply places the 12 items on the proper lane of the normal belt

I believe this would fix most of the issues.