Re: So... Let's talk about bots, and how to fix them properly...
Posted: Thu Mar 01, 2018 11:31 am
For everyone who is complaining about busses: I agree.
That's why you use spaghetti.
That's why you use spaghetti.
www.factorio.com
https://forums.factorio.com/
Which is effectively a Nerf... and Nerfs are usually hated upon by at least half the community as can be seen in other games as well. Wouldn't even be surprised if a lot of people would stop playing the game if Bots are nerfed this way because of how it renders their bases useless. So nerfing them is pretty much out of question.wvlad wrote:+1 for limiting robots that accessing chest at the same time
The red and blue underground belts already have been made much longer and it didn't change much.wvlad wrote:Also I would make underground belts x1.5 longer to make belts easier a bit (there are mods already).
You mean like the boxing/unboxing mod stuff where you require an assembler or other additional item to box/unbox everything? Pretty much like barreling... just for every item type?Aeternus wrote:Why not use the item's natural stack size instead? A crate with the sprite of the item overtop of it, indicating a full stack of whatever item it is from. That kind of mechanic should be compatible with any modded in items and eliminates the need for sprite stacking.
IE a special "Boxer" container that you dump for instance 280 metal into... outputs 2 "crates" of metal that represent a full stack of the stuff, leaving 80 behind in the boxing structure since it can't make a full stack out of it. You would not be able to load these boxes directly into assemblers, first unbox them.
Advantages:
- Extreme compression especially on high-stack items (those going to 200 especially).
- Unloading trains directly into boxing structures could allow for very high throughput through belts, especially for high-stack items
- Fewer moving units, helps with UPS
- Stuffing a box into an unboxer basically equates to the "inventory to inventory" you mentioned earlier. It'll allow stack inserters to be used to their fullest capacity.
Why would you ever NOT want to stack items once you are able to stack them?HurkWurk wrote:if we are going to go the stacking route, why not just add stack recipes to replace older single input recipes.
IE instead of a furnace using 5 iron plate to make 1 steel, it uses 5 crate iron (and X amount extra time) to make 1 crate steel.
each other recipie could also have crated versions.
No. That's a baaaaaad idea. If bots can't move crates, then you have no way of dealing with a crate spill that drops them all over the place. They can only be picked up by hand? That defeats the automation aspect of Factorio. Don't use solutions that make strange, scary problems.What if Bots can't carry crates?
This so far remains the coolest solution to belts vs. bots. Item stacking presents a few new inserter functions and puzzles for players to deal with. If I designed it I'd go forYou put them on the belt.Then you put more on the belt
This is a slightly optimistic assumption: because the bots only traverse one way. In reality, bots need to travel every distance twice (once to pick up something, and once to return to the starting location). So maybe 400-items per second is closer to the theoretical limit of bots (after infinite speed + infinite roboports).Logistic Bots : The Charging Network is the limitation. Assuming infinite speed (aka, literally infinite infinity research), Bots will still use 5.0kJ per meter. 4-bots per Roboport, each roboport is a 4x4 building with 1MW per bot recharge rate.
That's: 200 meters of charge per second, x4 bots per 4-squares of linear distance, with a cargo-size of 4 per Logistic Bot. I estimate a theoretical limit of ~800 items per second sustained per "lane" of Roboports. Having less than infinite research or having fewer than infinite roboports will lower the bandwidth. (ex: 10% roboport coverage, which is a Roboport every 40-tiles, would only sustain 80 items per second per roboport lane). "Bursting" bandwidth is strong due to the battery-packs of Logistic bots. A train-station may only be served every 15 seconds, giving more time for the roboports to charge more robots.
I agree... That is how it should look like more or less summed up. Stacks on the belt seems like the best solution dealing with most belt problems without introducing another load of problems.bobucles wrote:This so far remains the coolest solution to belts vs. bots. Item stacking presents a few new inserter functions and puzzles for players to deal with. If I designed it I'd go forYou put them on the belt.Then you put more on the belt
* only matching items stack
* only stack inserters(and maybe ore mines) can make stacks
* any type of inserter can grab from a stack
* Only the bottom item is tracked for belt compression (items don't magically slide across the top to compress)
The visual aspect stays simple. If you see a really thick item then you easily know it means multiple copies of that item. It simplifies things code wise as belt slots can be stored as "iron x 3" instead of "iron + iron + iron". The inserter rules mean that players have fine control over how they want to fill a belt, without presenting any problems when using resources from a belt. Stack inserters may also gain an extra option to control how high they want to stack. Stack inserters move 12 items per swing, so items should stack up to a nice multiple like 4 or 6.
Code: Select all
Belt Stack Max Size == Stack Inserter Max Size == Bot Cargo Max Size
bobucles wrote:Item crating doesn't tilt the balance between belts vs. bots. It only buffs both of them to absurd levels. If anything it ends up ruining trains! Why use a train when you can get even better throughput by belts? I like trains! I don't want to see them become second class logistics.What if Bots can't carry crates?
thats the whole point of this discussion though.. that somehow bots are strange and scary and need to be "delt with" in a way to make belts more capable.No. That's a baaaaaad idea. If bots can't move crates, then you have no way of dealing with a crate spill that drops them all over the place. They can only be picked up by hand? That defeats the automation aspect of Factorio. Don't use solutions that make strange, scary problems.
I agree on that. Beaconized setups are mainly the source of the problem of why we see so many bot based factories. I even have pointed it out in this thread already, and even on the controversial Friday Facts thread. I know it first hand because I am one of the bot-base guys who abandoned belts simply because they largely suck with Beaconized setups.HurkWurk wrote:to me, the real issue with bots is being able to beacon speed modules. this allows for a massive density increase that belts cannot compete with.
**IF** i wanted to make belts compete with bots, then the starting point would be to remove/alter beaconing. being based on space is too powerful. instead, i would make it so beaconing is a 1 to 1 ratio and that a dedicated wire between the beacon and target is needed, but having the standard wire range. in that way spaghetti belts could work around a new, smaller beacon device and only need a single (pink/purple/some other color) wire to connect to it.
personally i would do away with beacons and add another layer of machines. (machine 1 2 and 3 with more module slots, IE built in beacons)
That is exactly the opposite way of which belts and bots where initially intended. Back when the game started out it was intended that belts do the bulk transport and bots the low demand items.HurkWurk wrote:the other thing you could do tocripplelimit bots would be to limit the things they are allowed to transport. if logistic bots can only move intermediate goods, and all finished goods had to instead move by belts, then you force the use of both.
If you change one of them... the others need to be changed with it.Code: Select all
Belt Stack Max Size == Stack Inserter Max Size == Bot Cargo Max Size
But they're not equal. It's completely unfair to treat all stack sizes as equal because not all stacks process at the same rate. Bot stacks pile up in huge numbers and belt stacks would build up pretty quickly as well. Stack inserters utterly sluggish by comparison. Making all their cargo capacities equal "because same numbers are Equal" is a disaster in the making.Not sticking to that rule would result in giving either belts or bots an advantage or a disadvantage over the other.
I can't say I agree on this point. Beaconed productivity actually creates a huge REDUCTION in the need for item transport. Why?Beaconized setups are mainly the source of the problem of why we see so many bot based factories.
You completely failed to see my point.bobucles wrote:I don't follow. These things are not equal and they're the wrong comparisons to begin with. Inserters simply transfer items between sources and are not a (useful) method of long distance travel. Belts are a challenging method of moving items around. Bots are a simplified method of moving items around. A fair design ensures that easy solutions suffer some kind of downside over challenging solutions. Otherwise the latter becomes obsolete and that's a sad thing
[..]
But they're not equal. It's completely unfair to treat all stack sizes as equal because not all stacks process at the same rate. Bot stacks pile up in huge numbers and belt stacks would build up pretty quickly as well. Stack inserters utterly sluggish by comparison. Making all their cargo capacities equal "because same numbers are Equal" is a disaster in the making.
Bots have an item routing advantage that belts will NEVER have. Their current setup ALSO gives them some niche throughput advantages that belts struggle to compete against. Having one advantage but not another is a tradeoff. Having both advantages makes them flat out superior.
You are coming from the typical "theorycrafting" side of Beaconized PM3/SM3 setups... "PM3s reduce the amount required items etc"... yeah they do, and I am completely aware of all of that because I am using it myself and have even developed my own spreadsheets.bobucles wrote:I can't say I agree on this point. Beaconed productivity actually creates a huge REDUCTION in the need for item transport. Why?
1) Speed Beacon setups are physically more compact so that either belts or bots have less distance to travel. The same goal gets solved with fewer belts or bots overall.
2) Free item production reduces the number of raw materials a base needs. Thus fewer belts and bots are needed to meet the same goal.
A full prod3 chain cuts the cost of a rocket down to a third of its original cost, easily. It doesn't matter if your base is running 10 belts of ore or using 1000 bots to process an ore base. Without that productivity doing its thing, those numbers are automatically tripled. Instead of 10 short belts you now need 30 long belts, and instead of 1000 bots you need 3000 bots times a land multiplier to cover the extra real estate. The prod3 beacon base not only shrinks your base vertically(throughput) but horizontally (distance covered) as well, creating a power of 2 reduction in total amount of item movement your base requires.
I currently run a full prod3 beacon base off of a set of 40 iron and 40 copper lines. If I removed all the prod3 steps I would need over 120 iron and 120 copper lines to get the same number of rockets! It doesn't matter if bots or belts are stronger at that point, because either solution will struggle to move all those raw resources.
TLDR: Beacons aren't to blame for bots. If anything, a base without beacons is so logistically demanding that they can't be satisfied with either bots OR belts.
maybe its a nerf for bots but its a buff for realism.MeduSalem wrote:Which is effectively a Nerf... and Nerfs are usually hated upon by at least half the community as can be seen in other games as well. Wouldn't even be surprised if a lot of people would stop playing the game if Bots are nerfed this way because of how it renders their bases useless. So nerfing them is pretty much out of question.wvlad wrote:+1 for limiting robots that accessing chest at the same time
dragontamer5788 wrote:I apparently missed the debate. So I apologize if this has already been brought up before.
But Bots have a hard-cap on the bandwidth they can accomplish, determined by the charging time from each Roboport. I've written this up on Reddit.
This is a slightly optimistic assumption: because the bots only traverse one way. In reality, bots need to travel every distance twice (once to pick up something, and once to return to the starting location). So maybe 400-items per second is closer to the theoretical limit of bots (after infinite speed + infinite roboports).Logistic Bots : The Charging Network is the limitation. Assuming infinite speed (aka, literally infinite infinity research), Bots will still use 5.0kJ per meter. 4-bots per Roboport, each roboport is a 4x4 building with 1MW per bot recharge rate.
That's: 200 meters of charge per second, x4 bots per 4-squares of linear distance, with a cargo-size of 4 per Logistic Bot. I estimate a theoretical limit of ~800 items per second sustained per "lane" of Roboports. Having less than infinite research or having fewer than infinite roboports will lower the bandwidth. (ex: 10% roboport coverage, which is a Roboport every 40-tiles, would only sustain 80 items per second per roboport lane). "Bursting" bandwidth is strong due to the battery-packs of Logistic bots. A train-station may only be served every 15 seconds, giving more time for the roboports to charge more robots.
In short, a space with one-roboport every 40-tiles will only have the capacity of 2-blue belts due to the charging limitation. A dedicated line of Roboports would be 800-items per second (400-per-second, if you account for the return trip). Basically, if you want to "buff belts" so that they can compete with Roboports, simply make a belt that handles 100-items per second (to tie Roboports), or go higher if you wish for Belts to be superior. Maybe a 4x4 "Super-express Belt" system which can handle 500-items per second, or maybe 1200-items per second (+50% faster than what Roboports can currently accomplish) would be ideal. For proper balance, it should cost roughly the same as a Roboport (405 iron, 225 copper) per 4x4 unit.
Trains still win in theoretical bandwidth by an order of magnitude btw. I estimate a rail-line filled with 33% engines and 66% wagons would have a maximum bandwidth of 15773 items/sec (assuming an infinitely long train of 33% engines and 66% wagons). Reality has traffic, signals, and other such issues that would drop the efficiency by huge margins. But a well-designed rail-system realistically handles something on the order of 5000+ items per second. Not bad for a 2x2 unit that only costs 1 stone ore and 5.5 iron.
Ultimately, Roboports are actually in a cool position at ~400 items/sec (for a 4-wide design). Pure Roboports are still too slow to handle the output of a well designed train station (!!!). Consider a 4x station connected to a 2-4 wagon train system offloading Green Electric Circuits. To offload 4-trains would require movement of 128000 items, roughly at a rate of 1280 items/sec. It would require something on the order of 3x "lanes" of Roboports to handle this level of traffic.
I guess Roboports can be slightly nerfed, but the general feel of the game IMO benefits from making sure things don't get too good compared to trains. So I'd be wary of making any item in the game able to handle more than 400-items per second over 4-wide squares. Nothing should be faster than that IMO.
No, that still doesn't follow. There's nothing wrong with a belt stack size not being equal to inserter size. The only reason they should even share a common divisor is because it looks pretty. If a stack inserter dunks 12 items, it looks nice for it to drop 2x6 complete stacks or 3 stacks of 4 or 4 stacks of 3. It looks silly to dunk a stack of 10 and then a stack of 2. That's the only reason behind it.MeduSalem wrote: The problem is that belts not only suck because of their own throughput limitations. They also suck because of inserter limitations due to inventory-to-belt transfer. That is something most people seem to ignore and forget completely.
Therefore =>
Belt Stack Size = Inserter Stack Size
Yeah, well. Just like. Big deal. Regular inserters struggle to fill belts. We still use them. If stack inserters do 3 stacks of 4, that means you need the same number of stack inserters to stack-saturate a belt as it takes fast inserters to flat-saturate a belt. Using 5-6 inserters per side to saturate a belt is not a game breaker. Granted it would be nice if there was a higher throughput way to somehow load a belt (hinthint), but that is by no means an absolute requirement. It would simply be a convenient way to deal with full stack-saturated belts without pulling out a dozen stack inserters every time.But inserters struggle to fill belts!
False equivalence. Bot CPU and belt CPU are not equal. This is especially true with the new belt update, which allows large sections of belts to be processed as a single entity. Every bot increments every tick and while this is a fast process there is no real testing to compare them against belts. Don't make a demand for reasons that haven't even been tested.The reason why Bot Cargo Size is also important because of UPS concerns many players raise all the time. If you want belt stacks to have about the same performance as bots then 1 stack of the belt must correspond to 1 bot on the map or otherwise people will continue to use whatever requires less moving items to be calculated. So:
Bot Cargo Size = Belt Stack Size
Belt setups don't fail because of space restrictions. It's easy to fit 2 belts into a sandwich of beacons/assemblers and 3 or even 4 belts is possible with some clever spaghetti. They fail because those belts reach saturation almost immediately. By the time the beacon line just gets warmed up the belts are already at capacity and it's time to move to the next row. That's not a fault of beacons, that's a fault of belts failing to keep up. If you were to decompress that build into a much larger batch of slower prod3 assemblers in longer lines, those same belts will STILL fail to keep up because they didn't have the throughput to begin with.The problem starts when you try to implement that stuff with belts and find out that most of the belt related setups are for the garbage can because they just don't work at all because of how belts are too slow, because of how inserters are too slow, because of how you can't fit all the belts and inserters and electric poles between the beacons due to space restriction and whatnot... and all of that requiring massive amounts of hacks and workarounds to overcome, if even possible at all.
And that ratio would still favor bots. Because you have extra Inserters picking from the belt and dropping onto the belt, and travel time on the belt is longer then bots (bots are faster then even blue belts). That is why I advised a small 1x2 "loader" like structure that ejects not just a stack of max 13, but item stack size, with a chest/inventory on one side and a belt in/out on the other. Call it a pallet, crate or whatever - point is to compress a stack of something onto a belt. Which is a common thing to do in industry actually...MeduSalem wrote:The reason why Bot Cargo Size is also important because of UPS concerns many players raise all the time. If you want belt stacks to have about the same performance as bots then 1 stack of the belt must correspond to 1 bot on the map or otherwise people will continue to use whatever requires less moving items to be calculated.
Even before megabases, bots in their current form just... destroy the logistics complexity. Output? To yellow chest. Input? Blue chest. Done! With lower volumes pre-megabase, going full bot simplifies things. Which can be good, if you're still learning the intricacies of the game, and are figuring out what's what. Hells... when I first tried a Bobs mod game and tried expanding and setting up a chemical industry... I was blown away by the complexity of the production chains. It. Was. Insane. And without bots I'd have never figured everything out. Then you tear your initial stuff down (or leave it as a legacy to baby's first production chain) and set up bigger chains with mainly belts and local production.Also beaconized setups allowed people to push the limits of the game to where it is now in the first place where people all of a sudden require 200k Iron Ore/Minute and whatnot with like 80 belts in parallel just for one item type and crazy stuff like it. Without ridiculous megabases like those people wouldn't even be complaining about the gap between Belts and Bots.