Page 45 of 51

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

Posted: Wed Feb 07, 2018 1:06 pm
by Deadlock989
McDuff wrote:It is quite literally a problem that the devs themselves have raised.
Really? The devs said that it's a problem that a few players are bored of bots? Must have missed that. I thought this was about belts competing with bots in the late game, but clearly I've misunderstood.
Maybe it's not really a problem or maybe it is. Maybe the solutions are a few tweaks to bots or maybe it's a sign that something needs to be adjusted on a fundamental level. Either way the conversation was started and people have found it interesting to expand their thoughts on it. If you don't like it, might I suggest not reading it? Perhaps instead find a nice book and sit outside in the sunshine?
It's single digits on the thermometer outside and overcast, but I take your point. I'll leave y'all to sprinkling quantum pixie dust on belts or proposing wild changes that would completely spoil the game for the other half of the player base, were they not to be inevitably ignored.

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

Posted: Wed Feb 07, 2018 1:11 pm
by Pascali
Deadlock989 wrote:Which bit of "en masse" was hard to understand? I wasn't talking about individual players or modders. I'm talking about mass brain farts like this thread. A game developer would be insane to take much notice of it.
...and i am not en masse, and still loving belts - not bots.

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

Posted: Wed Feb 07, 2018 5:12 pm
by McDuff
OK dude thanks for stopping by though you've been an amazing help.

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

Posted: Wed Feb 07, 2018 9:58 pm
by inkognyto
Bots need a limiter. Right now there is zero drawback. The more they carry the slower they are, or drain more power. So if you overload bots on a long network they could get stuck recharging a lot. Sure you could be 'more' of them but then you need more power, resources etc, and if they get stuck on the 'low' power as they are overloaded then another port, another wait.

I'd also like to see a limit on how many can recharge in at a time. Delays and bottlenecks need to happen for them to be not optimal.

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

Posted: Wed Feb 07, 2018 11:02 pm
by RokRoland
Hi, moderate player here and I don't mind the bots but I found the blog to be interesting, however I did not think the devs were really exploring all the options for bot nerf or eventual belt buff, so I finally registered to output some thoughts which someone might find useful, hopefully.
PacifyerGrey wrote:Make bots consume greater amounts of energy based on active bots number in the network.
I think this idea contains the seed of an idea for increasing cost for additional bots.
Koub wrote: Have a base powered by nuclear with bots supplying nuclear cells to the reactors.
Add some bots.
Get a brownout.
Get steamrolled by the biters.
Start a new base.
This does not have to happen unpredicatably. The mechanic for increased power consumption for bots can be implemented in so many different ways that allows for graceful degradation of the bot network upon expansion in a predictable way.

To remind, I do not necessarily think bots need a nerf but because one is discussed, one method could apply elements presented here, referred to as penalty. Please don't hate me for discussing an item that has been brought up.

  • First, the penalty should be applied on the recharge effiency at the roboport, with a logarithmic efficiency multiplier based on the number of roboports present. This way the penalty can be applied either for recharge duration, power need, or both. Further bonus is that it is trivial to not apply this to the personal roboport, so ongoing player activites are not affected.
  • Second, the penalty should be applied on global basis. However a new building type (bulky, expensive, with meaningful power draw) could divide the areas where the penalty is applied, or offset the required penalty. This way there would be additional size and cost consideration upon introducing a bot network beyond a specific size with additional baseline power draw added. I have not thought about what happens if no power is supplied to this building. To implement just a simple production cost offset to expanding, it could be implemented in research only. Maybe it would eventually be just one more compulsory thing to add to all major bot-based blueprints, but it is a cost associated with bot usage none the less.
  • Third, the powerful researches that improve the efficiency of bots could also be introduced as roboport modules, not as automatic upgrades to bots. Of course with these modules there would be associated power draw penalties, and in conjunction with roboport amount penalty, they could work up to more significant numbers than on their own, because mathematics is beautiful.
In the end, in Factorio everything is production, resources, layout space, in one form or another - including energy. To nerf something does not mean it has to perform its function in more time, but it is also a nerf to consume more of some resource. Energy looks like a pretty good candidate because it is already connected to the usage of bots, and belts don't use any power at all. It is another issue that energy is relatively cheap to produce after a point. Well, build many bots, build lots (and lots more) of energy production sounds like a logical consequence.

With regards to belt improvements: The presented suggestions of the blog were pretty much inside the box, to just have stacks of items on belts. Here's some that are from outside the box, implementation details of any of these are probably rather significant, however that is an issue for the devs to consider, not for me. So, for endgame belt upgrades, some propeller hat ideas:
  • Quad layout belt (4 items side by side) as endgame upgrade. 100% increase over current performance. Work needs to be done on the visuals and inserting mechanisms. Technically it could also be considered a stack of 2 is just laid out side by side. Merging belts cause routing issue, though.
  • Triple layout belt (a middle item). 50% increase over current performance. Same issues as above. Needs specific inserters and splitters. Probably a lot of work.
  • Bi-planar belt: A belt that transports stuff in two levels. 100% increase over current performance.
With regards to triple and quad belt, maybe they are better off forgotten already. However with bi-planar belts, if you enforce a rule that items on top and bottom must be the same, it becomes a stack belt. So I didn't think of anything feasible which was not already suggested. But why not a stack belt?

In the blog under "New tier of belt which would be able to stack items." are a number of concerns that don't really seem that well thought out to me. There are several "if", all of which can be a "no" which then are no concern, except for the two items and a consequence:
  • 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.
  • If the stacks could only be created on the stack belt, but stay stacked on the normal belts, you would just build your insertion points, splitters and UG belts with the stack belt tier.
  • 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.
Ok, immediately I would say of course only stack belts can have stacks, and no stacks on normal belts. Whenever a stack belt meets a lower tier belt it would back up, and stack belts would automatically accept two identical items per square. Quite annoying? I think it is quite annoying already when a red belt meets yellow belt, this is no different and actually an extension of what the game mechanic already is. The same could be said for motivation about getting rid of normal belts ASAP: This always happens when a new belt tier becomes available, and actually this is a good thing for the game - to be motivated to go for the new technology ASAP - and not a bad thing! The graphical representation of stack is some issue, but if this is an unsolvable issue, you have succeeded in your game not because of your problem-solving capabilities.

If you want to nerf bots, add roboport recharge inefficiency multiplier increasing logarithmically with the amount of roboports, adjust "free" bot efficiency upgrades by making them modules which must be produced, inserted in roboports and invoke an energy based penalty, give a way to mitigate these new energy hogs by new buildings and/or research.
If you want to buff belts, just make the stacked belt already, there's no other excuse beyond some graphical work or coding work, both of which are inevitable in a game development project.
If you don't want to do either, I don't mind.

Thanks for the nice game and hopefully this is some food for thought (as opposed to troll bait).

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

Posted: Thu Feb 08, 2018 1:47 am
by Tricorius
inkognyto wrote:Bots need a limiter. Right now there is zero drawback. The more they carry the slower they are, or drain more power. So if you overload bots on a long network they could get stuck recharging a lot. Sure you could be 'more' of them but then you need more power, resources etc, and if they get stuck on the 'low' power as they are overloaded then another port, another wait.

I'd also like to see a limit on how many can recharge in at a time. Delays and bottlenecks need to happen for them to be not optimal.
All of this, with the exception of draining more when they carry more, is literally implemented in the current code.

N J think adding "weight" to the game is a bad idea for reasons already enumerated elsewhere.

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

Posted: Thu Feb 08, 2018 4:24 pm
by McDuff
Been rereading the FF post, and I think my suggestion here does actually do what Kovarex said:
They should still be a big and powerful advancement when they are researched, but they should work more like the death spell. It should solve the little stuff that isn't that powerful (in Factorio, it is equal to smaller production). I even believe that robot-only Factory should be possible and not useless, I just don't believe, that they should be 5+ times stronger than anything else.

I have been mulling it over and I think there's one additional thing that would need to be added: some buffer storage slots in the roboports themselves.

Without such a change, any "hops" would be broken if you forget to build a storage chest in a roboport cell. The storage slots themselves should not be usable by the user but just internal to the logistic network itself. This would mean hops could happen even if there are no storage chests in intermediate cells.

A long chain of hops would therefore go S[torage]-R[oboport]-R-R-R-B[uffer]. Adjacent cells could simply go S-B.

Keeping with the fractal/tree thing, Storage chests would more readily fall into place as their long term storage and buffer chests as fast-access caches.

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

Posted: Sat Feb 10, 2018 2:40 am
by Xordus
I must say, I fell hardcore for Factorio when it first released I played multiple maps before I finally got to the point of bot dominance. Once I reached that point I felt like the game didn't matter anymore. I didn't have to think anymore, I could just build a bunch of bots and they would just do everything for me. It completely ruined the game for me and I never really found the passion to reach that point again. I love optimizing bases for maximum throughput, organizing trainlines, defending outposts, but once I had bots all of that stuff felt so EASY that it drained the enjoyment completely.

To me Factorio is about challenge. You create your own goals within the framework of the game but the challenge is really with yourself. Can you figure out the best way to reach this or that goal. Once you have bots the answer to that question is obvious and the game loses meaning. You're no longer fighting your own mental limitations, you're just building more and bigger. The complex equations you spent 80 hours coming to terms with, the methods of efficiency you've developed, they just fade away and bots do the rest. To me, that's incredibly boring and directly competes with the goals of FACTORIO.

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

Posted: Sat Feb 10, 2018 3:00 am
by Xordus
I will also say to the Developer. Every change, especially major changes, to any game is met with resistance. It's not because the change is bad, it's because it's different and people like things they are accustomed to. It is your job to assess the strengths and weaknesses of your game, compare that to the desires of the playerbase, and then make the best decision FOR THE GAME. The players are fickle and will move past their angry forum posts and if necessary mod the game however they like. The game is more important than the desires of players. Players would prefer nuclear missiles and nanomachines, that doesn't mean those things are good for the game...

You can't undermine the product for the sake of appeasement... That's just poor game-design.

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

Posted: Sat Feb 10, 2018 10:30 am
by darth_sneaker
maybe neither "A", "B" or "C" is the solution but possibly adding choice would be.

We already have a lot of choices on new games - biter behaviour, evolution, receipt cost, resource distribution ...

If we add choices for game rules currently in question while adding a feedback formular that also uploads the replay, we would possibly gain a lot, especially choice for different types of players and a new way for the devs to (automatically) analyse how things are wanted and played together with feedback of what the users like or not.

Some of the ideas sound more easy to implement and might be first candidates for an evaluation:
- reduce number of robots ordered by requester- buffer- and active provider chests at a time
- some belt improvements
- increase robot energy consumption
- [...]
while choice should not be limited to easy-to-code things, but i think this could be an elegant way to get answers to questions like these.

on starting a new game these options could be activated and change in-game behaviour while activating replay and after reaching some given point presenting a feedback form when the player stops playing.

what do you think ?

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

Posted: Sat Feb 10, 2018 6:07 pm
by Xordus
The simplest fix is to remove all of the research buffs for logistic bots. The main reason they ruin the game is because they're so good, they're impossible not to use.

Good game design warrants an increase in complexity as you advance towards the endgame to properly challenge the player who's skill and competency has improved through hours of play. Factorio's bots directly contradict that rule in that they significantly decrease complexity while also exploding efficiency and negating competency. They nullify and waste much of the skill that the player has gained throughout the game and render the game's core technology (belts) virtually obsolete. They simply break the game...

They fundamentally alter the core tenants that FACTORIO is painstakingly built upon and make the game less fun to play... I know this is somewhat well-known, but given this widely held conclusion, it would seem negligent to ignore. Buffing belts isn't enough...

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

Posted: Mon Feb 12, 2018 3:07 am
Ok, here's a modest proposal of a framework for an agreement.

1. Whatever changes are made, they're hidden behind a map generation option. Existing bases with the current bot behavior continues to work, new maps could be created under the same circumstances. I think opinions are split too strongly to do it any other way

2. Now that people who are pro status quo can just use the status quo map setting ("strong bots" or some such), the only people left are people who want bots nerfed/balanced, so there's probably a lot more room to come to a compromise within that camp.

3. It is totally unnecessary to have the map setting be as ham handed as logistic bots totally on/off. The devs obviously like bots but don't like the way they're balanced, and feel constrained by the pro-botters from rebalancing them. Belts can be buffed some, bots nerfed, or some combination. I think the change could conceivably be as simple as limiting the number of simultaneous bots that can access a chest at a time. If that's it, or some set of similarly simple things, then it won't be a lot of work to keep the two map option variations maintained going forward. Frankly the belt buffs can be applied across the board, people don't seem to be arguing about that very much. It's the bot nerf that must be hidden behind an optional map setting.

4. I humbly suggest that the bot nerf be the default. The devs would obviously like to do this to preserve some of the complexity of the game for new players. But players who have become used to the existing behavior can flip one switch to turn it back that way. Biters on is the default, by design of the developers, but players who don't like it click one button to turn it off.

This keeps existing bot players happy, while giving those who think that the game needs to push/pull them in a little more balanced manner can have that too. Devs want the new players to experience the new behavior. Those who like strong bots will be no different than those who like no biters. Click, done.

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

Posted: Mon Feb 12, 2018 3:06 pm
by Aeternus
Xordus wrote:The simplest fix is to remove all of the research buffs for logistic bots. The main reason they ruin the game is because they're so good, they're impossible not to use.
This. They have high flexibility, but their drawback -should- be low throughput. They should be used on low volume transfers and player supply. Limiting bot cargo capacity to 1 will solve the thoughput issue.

[Edit] And for those who will say - you can solve that by more bots: True, but at some point you will run into bots backlogging at the charging stations. With boths only handling 1/5th of the current cargo capacity, you'd need 5 times the bots for the same throughput.

Suggest to replace the cargo capacity research path with bot endurance - increasing their energy capacity so they can move longer (and further) without needing to recharge. That will make them better at player supply (and the player controlled contruction bots will be more proficient at construction or bulldozing bursts).

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

Posted: Mon Feb 12, 2018 7:31 pm
by bobucles
bot endurance/ battery size
This is a pretty neat research option. It does not change the upper limit of a bot network by very much, since the main choke point is charging rate. Instead it gets bots across the map more quickly by reducing the times they need to run off and charge. In this way it will suffer diminishing total throughput returns just like raw bot speed.

Players will definitely feel the benefit of getting their items without having to wait for bots to charge. It is arguably more annoying to watch a supply bot get close and run away to recharge. A battery boost will reduce this from happening, and may be very helpful for personal robo bots as well.

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

Posted: Thu Feb 15, 2018 5:54 pm
by Deadly-Bagel
But that would utterly destroy a no-belts run which they said they didn't really want to do. I tried it myself and tbh I deleted the save, put too much Steel into Solar Panels which turned out to be worthless. Maybe I'll try again without biters. I do want to do it though, half of Factorio's gameplay is these fun little challenges you can set yourself.

Though I still don't really get the attraction of bots. They require a LOT of research to get going and only become "OP" in the late game when you're just blueprinting everything anyway so what's the difference if you're dropping belts or roboports other than a little space? I think we need to dig into why bots are good.

A blue belt moves 40 items over a tile per second. A bot can move 4 items max, base speed is 3 tiles per second, which from a throughput perspective over one tile is 12 items per second. You would therefore need 3.33 times bot speed for a single bot to match the throughput of a blue belt, which is just above Worker Robot Speed 6. So at "top" research level (if we consider 2,000 of each Science Pack to be excessive) their raw throughput is comparable, but bots are considered the masters of short-range throughput, why? A bot is not required to "load" its cargo, it instantly picks it up and drops it off, no waiting. A belt needs to wait for its Inserters to work, which absolutely kill short-range throughput. A max-level Stack Inserter probably makes a round between chest and belt about once per second, though only one lane is filled and not even compressed. So then there's a bunch of faffing to get both lanes compressed (which is currently broken) only to go through it all again at the other end. Bots can make several trips per charge, and with properly place Roboports and a few extra bots to fill in their throughput is not affected. Over a longer distance, however, that need to charge is much more painful and can have a robot taking large detours to charge. You cannot set their flight path either so Roboports need to be spread out through the factory to be ready to charge, though if a large request is suddenly made and a large number of robots take the same path, then what? They're all going to run out of charge at about the same time.

Surprisingly the build cost between a bot and an Express Transport Belt is pretty similar, while Roboports are needed for bots so are Stack Inserters for belts, and while robots are hideously more expensive to research up to speed than belts they also require less (but not a complete absence of) planning. The space used might be comparable (due to large number of roboports) but they can be spread out more.

So the biggest differences are the speed of loading/unloading, and the ease of implementation. Well, I don't think the latter is that much of an issue tbh, it's very difficult to get bots up to speed without solid belt lines and once you have it all researched and you're that far in the game then the belt planning is pretty trivial too and most of it can be blueprinted. That least load/unloading speed. Once they fix belt compression, I think if they set up Stack Inserters to "dump" items on the belt rather than let the belt run off with them, and similarly "suck" items up, then much of the loading/unloading grief is solved. I don't know why but I don't really like the idea of loaders and unloaders, seems a bit too easy I guess, but that would help too.

I think the majority of players just do what I do - use belts for the higher volume stuff in a bus down your factory, and use bots to move around small quantities of stuff (like Iron Ore for Concrete) and finished products.

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

Posted: Thu Feb 15, 2018 9:30 pm
by usafphoenix
one of the biggest problems with belts is compression, the number of inserts required to compress a belt makes bots the obvious choice unless you're using one of the mods that re-adds loaders into the game.
there are many ways to balance out (or make the decision more of a decison and not an obvious choice) the bots vs belts issue:

1) introduce a pallet system which bots cannot utilize (items such as coil, gears, engines, plates, etc), the intermediates---can all be palletized and enable belts to transport more items further, for less resources than bots, but require an extra stage in the factory (items must be packaged, and then unpackaged? ---or enable smart-crafting, that, is: the assembly factory is set to make gears from plates - an inserter picks up a pallet from a belt (these pallets CANNOT be placed in chests, or transported by bots), and inserts it into an assembly machine: it treats the pallet as X-amount of resources and begins crafting the gears.

2) limit the carrying "weight" capacity of robots. those tiny little droids shouldn't be able to carry a train! although....reasonably, i think a train would also crush a factory belt lol.

3) robots degrade over time, and either require charging more frequently, or require repairs which can become increasingly expensive as bases become larger and more and more robots begin operating at less efficiency, this can be entirely battery/energy based (they only recharge to 50% after X-amount of time in use, or after X-number of times fully charged, or if their battery ever fully depletes it stops recharging fully. propellers could break, and parts may need to be fixed, but with the simplicity of the current repair-pack system, i don't know if this is an adequate balancing method, and rather than nerf bots, i think it may be better to find ways to make belts more suitable (or less UPS costly)

btw: what causes the UPS drag? is it the rendering of tens of thousands of tiny little icons on animated belts? i imagine the memory and processing that involves is much higher than just rendering a bunch of flying robots on screen.

4) one of the things that makes bots superior to belts, and no changes to belts could improve: is the ability of the bots to supply, or de-junk the player's inventory. there really is no other solution to this, except by either A) increasing stack sizes to a high enough point, such that, the player can carry significantly more than before, or increasing the number of slots the player has in their inventory. This is a change that would neither nerf bots, or buff belts: it just makes bots less necessary to the player. one of the benefits of bots is their ability to help the player manage a debatably-insufficient inventory-carrying limit. By removing (or mitigating) this inventory limit, either by research, or by basic design, bots are less necessary to the player's ability to build, explore, and destroy the true enemy of factorio: trees. i mean biters. o

5) Had an idea awhile back that perhaps robots could transport a limited number of items: as in, they could only be taught to recognize and deliver certain things (similar to my idea above), butthis list of teachable items was limited, and perhaps could be expanded on using technology. i have no idea how this would be implemented, but it is essentially treating them like a real-world AI, that must be taught before it can accomplish anything useful.
say: first level robots could only recognize gears and basic green circuits. after research, they could also recognize coil and iron plate....or diverging technology might make it to where if they learned one set of items, they could not transport the other. this CHOICE, decision meant that the player would have to choose how to implement their robots and they'd have to deliver other items using belts, trains, or combination of both. I personally really liked the idea of diverging tech trees, where certain research would lock other technology. having a player able to build EVERYTHING i feel reduces replayability, whereas, limiting certain aspects can increase the re-playability by presenting an obvious opportunity to try the game a different way: this is kinda why i rage at them making the DEFAULT ore gen more similar to rail world, because it defeats the purpose of there being multiple game modes to CHOOSE from...they should be as different as possible to make the player WANT to try the other game modes.

on the topic of diverging tech trees: the possibility would be there, to say, make construction robots lock logistics robots out of the game: although i don't really support this, it would definitely achieve something: the benefit of logistic robots is matched only by their rival: the construction robots....if the player were forced to choose between them: which would they choose?
the problem with the idea of diverging tech trees is that the game simply doesn't provide enough technology content for there to be sufficient usage of this technique (there aren't 50 different guns to be researched, or 100 different armor pieces that can keep the player replaying over and over). And simply locking one type of robot exlusively against the other would just make most players bitter at the decision. (although in terms of balance, they are the only items that balance each other out).

I still feel like the idea to have a way to make belts more favorable either by providing features robots can't utilize, or by requiring costly maintenance to over-worked robots a possible method that can solve this particular debate

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

Posted: Fri Feb 16, 2018 8:57 am
by Aeternus
Reaction to the ideas above. I agree with some ideas, not so much with other ones.

1: The belts throughput remains an issue. Frankly, what is needed to be on-par with bots is a (near) infinite capacity "bulk belt" for main bus lines, which splitters can then split items off from. These "bulk transport belts" shouldn't be able to be grabbed from by inserters, but probably should have at least 10x the capacity of a blue belt. Specialized splitter required to convert from/to a normal belt. This is similar to the palletization but avoids the snafus that can happen when a belt with pallets gets destroyed or deconstructed by bots. Bots don't carry pallets, so what happens with whats on the belt?
Such a bulk belts should definately have loaders/unloaders associated with them to dump extremely high amounts of cargo into a train quickly. I'm not sure why loaders and unloaders were omitted from the base game. They are definately worthwhile additions for fans of belts.

2: Carrying weight is not possible.Weight is not a stat in the game, so it will not be able to be tested for.

3: Bot degradation and requiring maintenance isn't something I would support. It carries too many "what ifs". What about bots on a long trip to construct an object far away? Break down in the middle of that job and the item is lost? Would be annoying if it was just carrying a nuclear reactor... Other forms of transport and even all other structures don't degrade either in the game. There is no item with a negative health regen.
Besides, you'd run into the problem that construction bots armed with repair packs would go after every slightly degraded bot on the map, which results in a loop of bots chasing eachother for repairs.

4: There's no other mechanic then bots for automatic player supply? So. Make one. For instance: Endgame personal cargo teleporter as alterative - can "teleport" 1 item per second with high energy requirements. Player supply already has a limitation associated with it: The player has to be within the "orange" robogrid. Which means the player needs to be in the main base when you want to be supplied by bots. This is not an issue if you're tinkering with your main plant (and since you'll be reasonably near to the items you're being supplied with that just becomes a convenience rather then a necessity), but if you're out and about making mining outposts, bot supply is not likely to happen.

5: Limiting item types to be allowed by bots to carry would be annoying, it'd make player supply/trashing of items needlessly difficult.

Construction and logistics robots fill a different role. Making them mutually exclusive would cause me to grab the first mod that undoes this. They both have their place in the game - that Logistics robots are OP doesn't mean Constructon robots need a nerf, it means Logistics bots need balancing. They have too high a max throughput, so limit their cargo capacity to 2 and call it a day.

Diverging tech trees are an artificial limitation. Personally, I don't like having those in my games, especially if there's no sane reason for it. Why could you not research logistics bots after researching construction bots if he same resources are needed for said research? It's not like there's an unique alien McGimmick that players get only one of, that gets consumed in the research.

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

Posted: Fri Feb 16, 2018 11:43 am
by Caine
Aeternus wrote:Frankly, what is needed to be on-par with bots is a (near) infinite capacity "bulk belt" for main bus lines, which splitters can then split items off from.
I disagree. The problem here is that a belt based main bus is just poor factory design. It is the easiest way to play, but it does not (and should not) scale.

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

Posted: Fri Feb 16, 2018 4:11 pm
by Jap2.0
Caine wrote:
Aeternus wrote:Frankly, what is needed to be on-par with bots is a (near) infinite capacity "bulk belt" for main bus lines, which splitters can then split items off from.
I disagree. The problem here is that a belt based main bus is just poor factory design. It is the easiest way to play, but it does not (and should not) scale.
Yeah! When you want to build a belt megabase, you need spaghetti!

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

Posted: Fri Feb 16, 2018 6:41 pm
by Caine
Jap2.0 wrote:Yeah! When you want to build a belt megabase, you need spaghetti!
No you need trains, modular factory complexes and local minimum distance belt transport (ignoring bots for the moments since this is a belt vs bots topic).

View it like this: all items on a saturated main bus will never get used. It is an essentially a massive buffer to instantly transport an item from one end of your base to another. Every item consumed on one end will be immediately produced at the other end (otherwise it would not be saturated). Therefore the cost of a main bus is the cost of the belt and all the items on it. The longer your bus the more wasted products. For ores this is okay-ish, but for the more expensive intermediate products (like e.g. processing units) this is really bad since all those items could have been put to productive use instead.

A buffer needs to be large enough to cover the transport time between producer and consumer and the main bus concept takes this to its extreme for simplicity of construction. The buffer itself however, is WAY too big. In the ideal case your belts are as empty as possible without stalling any of the factories which they connect. However, this is insanely hard to do properly.

When you are doing a production challenge then you actually score points for all those items laying around (which is putting them to productive use), so then it is not that bad. But they could also be invested in more expensive products instead scoring you more points. Here it becomes a tradeoff with cost, benefit and time, which makes it interesting.

In case you don't give a shit, then none of this matters since it is a sandbox game which you can play in any way you like. However, to me, the main bus is the most boring and brain-dead way possible to play Factorio.