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

[Samlow]

Theyve actually talked about increasing the belt throughput directly through either stacking or packaging, but I think their counter arguments stand true. Stacking on belts doesn't improve their attractiveness for min maxing as long as bots can still do the same with now space restrictions.

[psihius]

Theyve actually talked about increasing the belt throughput directly through either stacking or packaging, but I think their counter arguments stand true. Stacking on belts doesn't improve their attractiveness for min maxing as long as bots can still do the same with now space restrictions.

Not necessarily. The optimizations coming in 0.17 to belts + stacking might actually give better throughput than bots can UPS wise on a distance (the longer it is, the better it is).

The big issue would be actually train unloading. The bigger the trains are, the more effective bots in a small area are.

[Avezo]

Btw. on a different note:
Why do you even have to visualize the amount of items in a stack on a belt to begin with? You don't visualize the amount of items that a Stack inserter (or normal inserters considering that you also get a few stack upgrades for normal inserters) is currently holding, so why would you need it for belts? As long it's only the same type it shouldn't really matter if that 1 item you see on the belt is actually just 1 item or X (X > 1) items.

I like seeing my belts full and in nice order, especially when they are fully compressed. If items are in the same spot or there are spaces inbetween, unequal stacks and such, it looks waaaay less cool.

[Samlow]

Btw. on a different note:
Why do you even have to visualize the amount of items in a stack on a belt to begin with? You don't visualize the amount of items that a Stack inserter (or normal inserters considering that you also get a few stack upgrades for normal inserters) is currently holding, so why would you need it for belts? As long it's only the same type it shouldn't really matter if that 1 item you see on the belt is actually just 1 item or X (X > 1) items.

I like seeing my belts full and in nice order, especially when they are fully compressed. If items are in the same spot or there are spaces inbetween, unequal stacks and such, it looks waaaay less cool.

Fully agree on that too! Its counter intuitive to try and fill belts if they will never fill because of stacks. Adding linear scaling to belts doesn't really solve linear scaling in bots right?

[Sigma1]

As someone already mentioned, 90 degree corner inserters as a late game tech would be pretty nice for compact belt layouts. Possibly even programmable ones?

[warlordship]

As a heavy belt user (I get bored before I get too far into mega-base territory), here are a few things I'd love to see that would keep me from changing over to bots more often:

Filter splitter - I love the filter splitter. I don't use mixed belts often, but it is a great change to the game. It could be a late-game tech (yellow/purple science req.) that simply adds new function to a splitter.

The death of filer inserters - While we're at it, let's get rid of filter inserters and stack filter inserters. Let those be unlocked from the same tech upgrade that filter inserters are given to us. There is no real reason to have a separate inserter entity that cannot be reverted back to fast inserter (like you can convert blues to purples).

Chest access limit - I suppose a 1/2 to 1/4 second access time for each chest would be a great way to limit bot overpowered-ness, forcing you to expand the number of chests and assemblers you needed to get the same overall throughput. This would also greatly nerf the "load up with productivity and speed modules around one magic assembler" trick that encourages bot use. (I am not a fan of heavy beacon use).

Logistics cargo bot - If you do the above, you must must MUST allow bots to carry more product. Maybe change logistics bots over to a logistics cargo bot (or add a new robot) so people can have 10-20 items delivered at a time per robot. In fact, the more I think about it, why NOT add a new cargo bot? Maybe it's slower, but can hold a lot more? That would mean people won't have to spam thousands of regular bots for the same throughput.

Liquid Bot - Can we get a liquid bot? I really dislike barrels, but I'd like to have a case where I can get a little bit of liquid delivered without having either an unsightly pipe (that blocks walking) or the added annoyance of dealing with barrel/unbarreling. A barreled belt or a liquid wagon train or pipes will still have better throughput, but at least my electric engine assemblers and blue belt assemblers that I have in my base won't need a dedicated line of lubricant among my other misc assembler buildings.

Train loaders - Can we get a train loader/unloader? Make it 1x6 and take in 2 belts in the center 2 tiles. The other side connects to a train and loads it as fast as 6 stack inserters are capable of loading a train (speed raises with stack inserter stack size research?). Turned the other way, it will SUCK the cargo from trains, and output onto the two belts fully compressed. I'd like this mostly because I HAVE to use bots to optimize balanced train loading/unloading to run as fast as the stack inserters can run. If I try belts, I either have to have an ugly abomination of a pyramid of splitters on each wagon side, or something involving UG belts.

Faster belts? - I wouldn't mind one more faster final tier of belt. Maybe change this one over to be requiring lubricant instead of the blue tier, so it's not just "pour more gears/iron at it" increase in cost. If you do this, though, please please PLEASE add an upgrade mechanic, perhaps using bots (I don't like using mods, so I don't know if the upgrade planner mod does this. But even if it does, please add it to base game).

- A minor annoyance, but when we use a splitter to combine 2 belts into one, can we not have any items sit on the unused output of the splitter? I hate seeing a wasted item, and picking it up once the 2-1 splitter merge is used up (like when I am removing two belts from exhausted mines and now have a worthless 2 ore sitting in my inventory).

I have yet another idea to improve belt throughput.
Make another tier "insanely-fast-betls" BUT inserters wouldn't be able to use it. This would help in mega factories when main buses have 8 or more belts for each basic material. Player would be able to use spliters to merge 2 (or even more) express belts so the bus don't take that much space. It would solve only some problems but it seems to be very easy to implement and don't interfere with any other game mechanics so maybe it is worth it.

This is a fantastic idea. It could maybe be a covered tube or taller stack belt, similar to the look of belts someone here linked:

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

Hah, I actually had an idea exactly like this, but then I realized that basically we are just asking for trains, but smaller. Right now, I'm not in favor of adding a 4th type of logistics, unless bots routed themselves on this (can go forward and back and take sharp turns) and can pass eachother (for congestion). But then, it just becomes a type of logistics bots (no collision, no throughput limit) but has to use physical world-space. I really am unsure about the viability or use for this (unless it replaced free-flying bots entirely).

As someone already mentioned, 90 degree corner inserters as a late game tech would be pretty nice for compact belt layouts. Possibly even programmable ones?

Oh my, I forgot about this. I am 100% in favor of this. But, like I said about filter inserters up above, please PLEASE make it a configure option/research for normal inserters. Do not force me to carry around a few hundred normal inserters AND a few hundred corner inserters AND a few hundred stack inserters when I build things.

[Slayn25]

Technology which would turn all belts into stack belts.
You would research this and automagically all inserters, splitters and side-loading (also mining drills) would be able to make stacks on any type of the 3 belt tiers we have now.
You don't get any new entity, but you get the choice between upgrading all of your belts with this technology and not having to do any extra work, or tearing up your base and replacing with robots.

Alternatively if you wanted to add a new entity and not change how existing setups function you could limit belt stacking functionality to a "stack splitter"

[Lubricus]

I think you have overestimated how OP and easy to use bots are. In mid game they are slow and eat a lot of power so it's better to use belts if you can.
Then you have to be careful not to build to big logistics network where the have a tendency to derp around and fly far away for some silly thing...
In Megabases optimizing flight path of the bots is tricky and important, hence the factories are divided up in not to large logistic networks divided by bot-bridges or trains.
Said that, I think logistic bots are a little to powerfull in combination with requester chests. And at the same time i think construction bots should be buffed and easier to get to, and it's also nice to have bots fetch stuff so you don't need to run back and forth to the shopingmal all the time.
An interesting idea to balance it I saw somewhere on the forum was to nerf the requester chests not the bots.
Comments to belt buffs
1. Packed items like pallets/containers - Couldn't you do some easier solution than assemblers with inserters to package, unpackage. Maybe a smaler entity that but out the stuff automatically as miners do. To balance against other transport solution let the containers only stack to 1. The containers shouldn't be used everywhere just where extreme throughput is needed.
2. New tier of belt which would be able to stack items.
"If only the stack belt is allowed to have stacks, then whenever items move to a single tile of a normal belt, all of the items would un-stack, which woulbe be quite annoying." -Why is that annoying? I think it would be cool if the stuff unstack after a split where the throughput isn't needed.
"Both of the previous points might not be the worst thing but it would be quite weird and would motivate you to just get rid of all normal belts ASAP." -The same argument could be said against stack inserters and blue belts and half the game.
"If only inserters would be able to create the stacks, it would get really annoying to attempt making a fully compressed, fully stacked belt even if inserters auto-compressed the belt." -That is great game design, to come up with the perfect solution should be impossible and something we can argue about in the forum for years to come.

[warlordship]

Technology which would turn all belts into stack belts.
You would research this and automagically all inserters, splitters and side-loading (also mining drills) would be able to make stacks on any type of the 3 belt tiers we have now.
You don't get any new entity, but you get the choice between upgrading all of your belts with this technology and not having to do any extra work, or tearing up your base and replacing with robots.

Alternatively if you wanted to add a new entity and not change how existing setups function you could limit belt stacking functionality to a "stack splitter"

Or a.... *coughs* ...stack inserter?

[TheGrandUser]

With regards to exploring other planets in the context of bots, bots need air to fly around, right? Not much use for bots on an airless moon, and it's a great place for microgravity manufacturing as well as potential unique materials.

[jeriktelorian]

I think the solution might be to make Logi bots more complex to field, rather than to slow them down.

Make them be used like an airport might -- you deliver materials to a roboport with belts, and bots from that roboport are dispatched to deliver those items to other roboports that request them, where they are loaded onto belts to go to their destination. This can then include loading/unloading queues that can be improved with research to make them more efficient.

In addition, this increases the footprint for roboports, so you can't just slap a chest where it's convenient. It will take some planning to implement.

[Samlow]

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

Hah, I actually had an idea exactly like this, but then I realized that basically we are just asking for trains, but smaller. Right now, I'm not in favor of adding a 4th type of logistics, unless bots routed themselves on this (can go forward and back and take sharp turns) and can pass eachother (for congestion). But then, it just becomes a type of logistics bots (no collision, no throughput limit) but has to use physical world-space. I really am unsure about the viability or use for this (unless it replaced free-flying bots entirely).

Thats exactly what Im asking for, but with a caveat: The tracks would be elevated, so they co-excist with the excisting base. Youre limited to loading/unloading at a slightly bigger structure that is fixed to the ground.

In terms of logic and pathfinding / smart carts, this could be research locked, but the initial intent is to provide a smaller scale high volume, less space restrained transport option.

EDIT Addition:
Not saying having them be smart is what I want, but I want them to be manipulatable. Id have the carts be dumb though, mostly to keep it UPS friendly. The smart part will be the puzzle in setting the rails, rail switches, and load/unload filters to be optimal.

This would need a workable proof of concept mod to show its potential though.

[warlordship]

Hah, I actually had an idea exactly like this, but then I realized that basically we are just asking for trains, but smaller. Right now, I'm not in favor of adding a 4th type of logistics, unless bots routed themselves on this (can go forward and back and take sharp turns) and can pass eachother (for congestion). But then, it just becomes a type of logistics bots (no collision, no throughput limit) but has to use physical world-space. I really am unsure about the viability or use for this (unless it replaced free-flying bots entirely).

Thats exactly what Im asking for, but with a caveat: The tracks would be elevated, so they co-excist with the excisting base. Youre limited to loading/unloading at a slightly bigger structure that is fixed to the ground.

In terms of logic and pathfinding / smart carts, this could be research locked, but the initial intent is to provide a smaller scale high volume, less space restrained transport option.

So you want these monorails to be a whole new layer to the game? You'd be able to build rails that can go over existing buildings like assemblers and power poles? In this case, why not make it an underground sub-way style? It's look a lot less ugly, and might even come with the added benefit of having to work with/conflict with underground belts/underground pipes. I'd actually love to see UG pipes/belts change into simply a second layer of the game, but only for belts and pipes (and bot subways, I suppose).

Now that I think about it, this would be a way to do "express/stack belts" that cannot be interacted with by inserters, as suggested earlier. Since you wouldn't grab contents of UG belts with inserters until you bring them up, this could serve as a way to implement that restriction.

Oh, and UG belts or stack belts (whichever they implement) won't animate, so hopefully that can help cut down on ups drain?

[Triaxx2]

My suggestion of two types of bots still stands. One Cargo Type that has much higher carry capacity, say 8-24 items, but is very slow. And then a second Logistics type that carries 2-4 items, but is much faster. That one that can catch up with the player, but doesn't carry a huge amount.

Alternately, tweak belts not to be faster, but to carry more items with each tier. Yellow carries 8 items, Red carries 16, and Blue carries 24. This way you can still push much more material through the space without having to run multiple belts. IE if you're running a Main Bus with 4 Yellow Iron belts, you can reduce that to 2 Red, or 1 Blue and 1 Yellow. Or let Blue carry 32 items per tile and have it be 4>2>1 as you upgrade.

On the other hand, Bob's mod added two more tiers of belt without significantly breaking the game.

[DanGio]

Hi there! Nice FFF! Can't even imagine you were talking about ending this blog few weeks ago...

My position on the subject is strongly neutral. I'm not a megabase guy, so...bots are OP, but if megabases need them well let them be, not my problem.

[Nick-Nack]

The splitters are really awesome! Please make the filter changeable via circuit network, and they will solve a lot of problems I had in more complex belt set ups.

Concerning the bots after reading the discussion from last week I came to the conclusion that there is a simple yet effective solution:
Implement that bots take time to deliver goods.
If a requesting chest is blocked for some seconds after a bot starts or lands, this would not prohibit players from creating massive bot based bases, because they could still just pop down a lot of chests, but, and this the important part: scaling up would require actual space. Currently it doesn't, which is the only reason why bots have a massive advantage compared to belts. Concerning the time it is important to take into account the maximum robot cargo size as well as a reasonable number of chests that are used at the same time (3?).

[anarcobra]

I find any game with mechanics and units to be more interesting when there's an assortment to choose from and each has its place. There's definitive trade-offs with pros and cons the player is faced with to weigh and ultimately deal with. If the choice of what to do is always so obvious, appeal is quickly lost. When one solution is 5x better than the other, that trade-off relationship breaks down. If you like implementing efficiency above all else, you're switching over to bots apparently. I always used bots as a supplement for priority, low quantity items. I wish I hadn't read any of this. Knowing that I can't possibly be as efficient with a mostly belt setup is a bummer. Yes, I'm aware you can set personal goals with game like this - I could be going for being as efficient as possible with just belts. It's a nice little personal goal, but before long the unwelcome thought of how you could be doing so much more with bots will inevitably come back at some point. This includes trying to compare your throughput to others.

As a game designer, this lack of trade-off concerning a fundamental system (logistics for this game) would plague my thoughts. As above, it'll do the same to me as a player. I would absolutely take measures to equalize the two approaches, so the choice of which system to use is not so one-sided.

It's hard to nerf something players are so attached to. Seeing your factory produce much less won't be seen well no matter how good the reasoning behind the change is.

I don't really agree with this, respectfully of course. I don't think your (developers) design decisions, that will stand for the life of the product, should cater to those who wish to keep playing the same factory through multiple major releases. I also don't agree with the apparent acquiescence to these players who continually demand that their existing creations continue to function in ways they're used to. If a player is after that, they're welcome to continue playing an old version. What about your new players or players who start a new factory for every release?

Let's not forget that this is an early-access game. I'd rather have a game with thought provoking trade-offs and design decisions than the knowledge that existing players didn't have their current factories break or had to step outside their comfort zone. That means little to me now, and certainly will mean nothing when I play this game years from now.

I'm not crazy about the splitter changes. I used to enjoy the complexity and challenge to properly manage a sushi belt or make a priority splitter (even if it wasn't absolutely perfect down to every last item). This is just one more thought-provoking feature that was replaced by a one-click solution.

The problem isn't so much that existing factories will be broken (as far as I can tell) as it is that if you remove or significantly nerf bots, then the next version of factorio will support only smaller factories than the current version.
That seems like an obvious step back, and I think that is what many people are complaining about. Also the fact that to me and some others messing around with belts for untold hours gets old quick, and there is no real difference between blueprinting belts or robots.

[Slayn25]

Love the changes to splitters especially the priority functions. TBH I'd rather have a filter on electric mining drills than splitters though.

[psihius]

Here's a thought - grear logistic robots towards handling "peak demand" and not "sustained". Leave what robots are good en mass - unloading/loading trains, satisfying smaller production areas, supplying players. That way, any significant throughput requirement cannot be met by bots, because they "run out of steam" and need to recharge or something like that. A bot should be able to fly for quite a while and distance, but as soon as he's done - it takes long time to get back into the game, effectively lowering the possible throughput.

[Killcreek2]

Such insights into the dev discussions, marvellous read! Thank you for taking the time to explain your thoughts. You guys are #1.

Removing bot cargo research does look like the best of those options, to be fair.

Technology which would turn all belts into stack belts.

If you can figure out how to make this idea work, it would be the perfect answer for endgame belt use viability. A small number at the corner of the item would do fine to indicate a stack (as OrigamiGuru suggests on page 2).
Fingers crossed!


Smart splitters are coming! YES!

Happy!.gif (6.15 KiB) Viewed 10569 times

(PS ~ to the moderators: Great job moderating the last FFF thread, letting the discussions run & only stepping in when necessary. Bravo!
You guys don't receive enough praise for the job you do, so: Thank You from me.)