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

[ignatio]

The thing that makes bots unbalanced is that they scale indefinitely for getting things in and out of chests.

Inserters have a limited throughput, and one can only place so many of them around a chest or machine. Why doesn't bots have a similar limitation? It seems reasonable that only one or a few can load or unload at the same time, and that each load/unload takes a couple of ticks.

Spontaneously I'd say bot load/unload throughput should be on par with fast inserters when the cargo size tech is maxed out. They should certainly have significantly less throughput than stack inserters. For high-volume items it'd mean one would either have to use several more chests per machine to create enough loading points to get equivalent throughput with bots, or else use more and slower machines and just spread out a lot more.

[Mimos]

Im sorry when i miss something similar, but my idea is based on something, for what i do not know an other word for then "hitbox".

As for an example: Trains have a hitbox, so they cant pass each other when they are on the same rail. Nothing new so far, but what if robots would get a hitbox too? This would limit Robots at a Point where adding just more Robots wouldt increase througtput. The Size of this hitbox could be used as a new way to balance the Robots.
For an example in an example: a robot have a hitbox of 1x1 titles, a movement speed of 11,25 tiles/s (Dobble as blue belt, dont know how mutch it is right now) and can carry 3 items at the same time means that you could limit one lane of robots (Point to Point) to 30 items/s. This could be interpreted as an item density for Robots (5,333 items/tile vs blue belt with 7,111 items/tile).

i dont know if my calculations are right but numbers indicate the potential balancing.

What do you think?

That would probably sadly come at an enormous UPS cost. Which would as a side effect discourage using bots, which I think is a bad idea even under the assumption that nerfing bots was a good idea.

[milo christiansen]

I would suggest % belt speed boost research (infinite?) along the same one for loaders (included or separate), this way wouldn't affect bots but would boost belts

I am strongly against any kind of belt speed research as it would destroy any circuit controlled belt machine every time you hit a new research level.

Many, many devices based on belts and combinators depend on specific speeds.

[Koub]

I'm a bit surprised about some of the reactions of the last FFF because, at least for me, it was clear that the bots would stay.

Yeah, I have no idea why people freaked out so much. It was very obvious that the post was somewhat theoretical and more of a "what if". That if things were built from scratch now, bots would look different, but that they can't change things too drastically after the fact. That's also why it's not a contradiction at all to say "I feel that bots need a debuff, but they won't be nerfed much".
But it's typical of the internet that people completely overreact and whine over nothing.

You're on the internet, and it's 2018 ... people are used to clickbaits, and the more outrageously extreme they can imagine, the better. I'm sure the worst haters didn't even read the whole FFF224, and started outright interpreting from the 2 first lines. People also have overall less inhibitions when they are online. And lastly, the vast majority of the contributions were okay. Heated-up a little, because the subject was terribly polemic, but reasonably. There were many contributors, and more than that, there were a huge number of people who registered or made their first post just on the FFF-224 topic. On such a crowd, mathematically, there will be a pair of assholes .

Now back to topic. I really think just comparing peak throughput of optimal bot network with 4 blue belts is looking at only part of the picture.
- What's the investment to create both setups in terms of resources ?
- Can we also have a look at the power consumtion of both setups ?
- Can we make the same experiment with double the length ?

It's like comparing a Lamborghini and a family car. Sure the Lamborghini can outrace any family car. But ... https://www.youtube.com/watch?v=JC-cx040cl0

[ctrlaltdel02]

Any bots nerf will be useless, it will get compensated with more bots and, or roboports. If only there was way to limit how much bots is allowed per area. Say, each roboport can support stack of bots, want more bots in roboports coverage working, you must build another roboport to overlay roboports working areas, that way you would be limited how much useful factory you could build vs how much roboports. So you will get to find optimal ratio between roboports vs factory, because of that if you built huge amount of roboports, there would just not be room for the factory for them to serve.

[milo christiansen]

Any bots nerf will be useless, it will get compensated with more bots and, or roboports. If only there was way to limit how much bots is allowed per area. Say, each roboport can support stack of bots, want more bots in roboports coverage working, you must build another roboport to overlay roboports working areas, that way you would be limited how much useful factory you could build vs how much roboports. So you will get to find optimal ratio between roboports vs factory, because of that if you built huge amount of roboports, there would just not be room for the factory for them to serve.

Similar to the personal roboport robot limit? I like it!

[drcrab]

i pretty much never use bots because i find them to be boring compared to the fun of working out belt paths, etc.

one idea (maybe this has been posted, i don't have time to read the whole thread, sorry) is to give items a "weight" or "size" and base bot speed on the weight/size of the items they're carrying. This doesn't have to be rooted in reality, but make it progress so that higher tier items "weigh" more. So a bot could transport a copper plate at 1x speed, but a satellite part at .05 speed, or something similar. It'd be sort of like the death spell in that bots would be great for early logistics, but actually kind of terrible for higher tier things. When setting up a new factory in addition to your original, you could use bots to bootstrap your core products and then switch to belts for the more advanced stuff. It wouldn't be a super cut and dry point where you'd want to switch over, it'd depend on how far the bots had to travel, the volume of stuff you wanted to move, etc.

[Visione]

I would suggest % belt speed boost research (infinite?) along the same one for loaders (included or separate), this way wouldn't affect bots but would boost belts

I am strongly against any kind of belt speed research as it would destroy any circuit controlled belt machine every time you hit a new research level.

Many, many devices based on belts and combinators depend on specific speeds.

I think its wrong to shoot a very good option just because some people use circuit controlled belt machines,
I get it, you should be able still be doing that aswell. Which you are, by not researching it.

[RawX]

I like how much thought you put into this and i like your suggestions. Because you were speaking so much about research: Maybe make the filter function for splitters a new research building upon blue belts?

I have a "lot" of bots, but most of them aren't doing much really. I like to use them to automate some of the seldom needed stuff. Otherwise they'd be too annoying, like flies buzzing around you all the time

I really like this game and how much you communicate the development process with the community, keep it up

[Antilope]

Add physical space to bots. Right now they can stay in the same place at the same time, what if they have to stop and dont run into each others? What about loading/unloading time? (inserters need time to put/pull material in chests) It is a realisitc nerf, the problem is solved.

[Caine]

I think its wrong to shoot a very good option just because some people use circuit controlled belt machines,
I get it, you should be able still be doing that aswell. Which you are, by not researching it.

I have to agree with Milo Christiansen here. The goal should be to improve how different game mechanics interact together not forcing the player to choose one above the other. Don't use it is not a great argument for improving overall game balance.

[WIZ4]

We hope, we are waiting. Stack-belt

Stack-belt.gif (23.21 MiB) Viewed 7867 times

[Mimos]

But most of all I would love to see a new transport mode which sits in between bots and belts:
Codenamed: Robots on rails

Basically, I envisage a monorail type system, with elevated tracks, where carts with boxes of items follow a set path direction.

This could consist of several components
- Track
- Loader
- Unloader
- Control station
You could also add some extras like a track switch or something. Every track should be as big as a belt, the others 2x1.

On top of the track, there would be 1x1 robot trains driving in one direction. Their logic could be anything from a simple "drive this way" to programmed, depending on how much dev time is spent on that lol. They would functions as such:

- Tracks can be placed "in the air" basically passing over other structures. They are direction agnostic just like train tracks. There could be switch tracks that are logic gate controlled.
- Loaders and unloaders Have a single piece of track on one side, and a item loader/unloader on the other. The loader unloader part functions exactly like the loader redux / mini loader addon. They fast-place/remove items from a belt into/out of their own buffer inventory. Then whenever a cart passes overhead, it loads/unloads them, possibly filtered (filter in the station, not the cart), when done, the cart passes on.
- Control station: could be combined with a switch track, but their main function is to provide the tracks with power and possibly be the cart spawner.

Carts
They would basically be moving chests. Possibly with a filter option, but definitely with the option to limit the number of stacks in each, just like an actual chest.

Research
Ofcourse this could have several tiers. There could be several tiers of carts and loaders/unloaders, and infinite speed/acceleration research if you want. I would place the most basic version before tier 3 belts.

Application
Its basically an in between belts trains and bots. Its not as high capacity or speed as trains (1-5 stacks per cart). Its not as point flexible like bots and belts. However, it is relatively spaghetti friendly, and high throughput, and scales with cart numbers and speed. I envisage a system like this as a main bus replacement / alternative, with unloaders at every side-branch instead of a splitter. It would be flexible enough by going over existing structures and infrastructure, but possibly be limited by not being able to cross its own tracks without providing risk (depending on if theres a track switch added), and not only solves a problem, but provides additional gameplay thats not just a: Belts but with more throughput.

Realistically
Now, my main challenge is that the game is already pretty feature complete, and a system like this would take quite some time. However, if theres some modder out there that would like to pick this up, I would love to give you a hand on deepening the project/balance.

I like the idea. I just hope I can still see the belts on the ground with all the monorails running over my head. This sometimes became a problems in Rollercoaster Tycoon end especially Locomotion when building high density stations.

[Slayn25]

I'm split on beacons myself. Nice having late game goals but yeah often times I find them more tedious than fun (for belts.) To be optimal you have to use "the layout" which kills direct insertion. Also when you're restricted to 2 squares on either side of the assembler you can't achieve inherent balance with hardly any recipes (use all of your input and output a compressed belt.) Although if I'm being honest inherent balance is just a dream once you start using productivity modules.

[Moin]

Hey,

and yeah my first post on this Forum and I hope I don't destroy some dreams . (Because of my "brilliant" ability to write in English, God save GoogleTranslator). And the second hope is that nobody wrote this idea in a previous post... Sorry thats too much english at 24am .

I read the FFF and then i realised, the whole game is "realistic", but not the bots. (Even the smoke and water are "realistic"). My Suggestion for this problem is:

The bots reload at the roboport, but max is 4 bots per roboport. Yeah thats realistic or not? But why not at the chest, too? So my idea is that at the chest only 4 bots can load or unload items in or from their storage and their need some time for it. If this nerf is to much, perhaps the bots can load 12 items instead of 2 or 4 or 6.

And yeah I like to see a buff of the belts, too .

[Inv1s1ble]

First post here on the forums and first of all SORRY, I did not read through all of the posts. I just wanted to share some ideas in the hope it might help on the bots vs belts topic. So here are my two cents:

Rather than to buff / debuff one of them I suggest to combine them - make them interact and benefit from each other. This way it would be a good thing to research and use both but also nobody had to decide between them, which could mean an end to the "VS-discussion" and ideally the interaction gives opportunities to find creative and fun solutions to optimize it.

So a little bit more specific I thought about a new functionality/property of the bots (or the belts) that let the robots support the belts thereby increasing the belt efficiency or throughput. The basic principle being: The more bots - the better the belts.

Some concrete ideas how an interaction between belts and bots could look like in the game:

• Robots require constant charging. Belts are able to charge robots. Result: Robots need to fly above or next to belts.
• Add two new entities to the game: 1. load belt box , 2. unload belt box. Both need to be placed on a belt. Robots primarily move stuff from the load to the unload box. So this helps increase the throughput of the belt and enables longer belt driven assembly lines.
• Enable bots to unload their cargo onto belts where ever there are free spots on the belt.
• New entity "belt stacker", which a belt runs through. Bots dock onto the belt stacker and stack the contents of the belt. The more bots you use in one belt stacker the faster stuff can be stacked. Maybe even have a "belt unstacker" which uses bots to make normal belt content out of stacks.

I am pretty sure those concrete ideas are not the best way how to implement the principle mentioned above in the game. But in case the principle is worth of thinking further about, I am pretty sure you will come up with some amazing and way better ideas than I could come up with
Thanks for reading
Inv1s1ble

PS: In case someone else already came up with that: Sorry! I did not copy intentionally.

[deer_buster]

I would like to suggest that a splitter could also be setup to take two belts of different items and output 1 or 2 belts of items with those 2 items each taking up a single lane of each belt, or perhaps a lane filter (much like the lane filter on the creative mod's matter creator)

[Avezo]

We hope, we are waiting. Stack-belt

Stack-belt.gif

This actually looks amazing! When hearing about stack belt I were thinking about something that makes seeing full belt wonky, but if this is how it's supposed to be, I wouldn't mind that much. Hope it also compresses upwards to max stack when consumption is lower than belt delivery.

This is actually interesting, if it's possible to increase stacks on the belt, is it needed to increase its speed ever? I.e. we would have all belts the same speed as yellow belt, but new belts would allow more stacks? Balancing it all so actual throughtput stays the same?

[Serenity]

and more than that, there were a huge number of people who registered or made their first post just on the FFF-224 topic.

Many of them probably told to do so by certain overreacting YouTubers

[Dranzer]

Okay, one thing at a time:

Splitter Changes: YES. God, yes, absolutely, 100%, fantastic, great, perfect. This is exactly the kind of thing that belts need. A couple of other things I'd really like to see are "Balance input" (i.e. alternate input regardless of the backup) and also, I've said it before and I'll say it again: Single tile splitters.

Regarding bot nerfs, an actual chest access cooldown may be worth a lot. An inserter can only access a chest so quickly, and you can only ever have four (well technically eight) inserters accessing a chest at a time. It doesn't have to be crippling, but it might go a long way towards making bots a situation for "Tricky configurations" - Hell, that might even be a reason to buff logistics bots in other respects - if they have to compete with inserters for speed, then they could maintain their use as a flexibility tool whilst leaving major hauling to belts, and then you could reduce their tech/production cost, maybe even make roboports smaller. That way trains -> belts -> bots could be about trading throughput for flexibility. Maybe. It's just a thought.

Also, while I'm mindlessly spitting out ideas: If you're going to let splitters filter, maybe it's time you let inserters filter innately? It's not really that significant a tool anymore, so it might as well be a universal thing. Hell, inserters are the kind of thing that could use a lot of love. I'd love to see inserters be more.. I guess, configurable? Like, what if you could choose where an inserter inputs and outputs from, to have L-shaped inserters? Which if long inserters came in multiple speeds? What if inserters had module slots and specialized modules for range, flexibility (choosing input/output tiles), filtering, stacking? What if you could just color them?

But I'm getting carried away here. You guys are doing good work.