It's probably for the best that I can only really play Factorio on my computer and not on my Steam Deck (yes, I _can_ but it's annoying enough to not have a mouse/keyboard that I don't). It's really an amazing game that you can dump literally thousands of hours into, trust me I have. I'm looking forward to new expansion even if it's still ~1 year out.
I’m really glad 2.0 isn’t released yet. I still have time to blacklist the domain so that I don’t get notified when it is released.
I think next playthrough I should use a city block template, those will have placeholders for roboports. However, I think they don't get placed if you haven't unlocked the technology yet, so a QoL improvement would be to be able to place a placeholder or spacer instead. Or just allow the placement of a ghost without researching the tech.
I've used the city block design blueprints in an attempt to do the Space Exploration mod; it worked alright, except that the templates had concrete flooring. That was a lot of concrete!
But anyway, next playthrough I should make a robot driven base, at least for anything but the high volume base materials like iron, copper and steel. Maybe I should build or get some blueprints for a main bus as well, especially for liquids.
These are certainly welcome changes for the bot-users. But now the balance of belts vs bots has been upset once more.
Belts were immune to these issues, and were a key advantage for handling these cases. Now that bots solve these issues, bot-based bases are going to gain more "strength" in the meta.
I recognize this is a bit of a (https://xkcd.com/1172/) joke, but I'm serious! Factorio is a game and a meta-game, with belt-based players in (friendly) debates vs bot-based players.
Since belts vs bots haven't changed in literally years, things have settled down and the debates have stopped. But now this changes things once more. I kinda-sorta feel like belts will need a +10% or +15% speed buff or something to keep the balance, because these are _huge_ improvements to bots IMO.
--------------
I guess belts are still fully deterministic and zero-power. So they're still useful in this new meta. But this "loop" example was commonly solved by running a belt (or train) across the troublesome path. Now bots can solve the problem by themselves.
All my factories end up decentralized with each node producing one or very rarely two outputs, and consuming only what they need. Trains transport everything between nodes, with one or more train per product type, with stations enabling or disabling automatically based on input starvation or output backlogging. But importantly, nothing besides 2x4 or 4x8 trains keeps up with the throughput without having stupid huge numbers of logistics bots. So trains end up being the majority of the transit.
Within a node it's majority belts, but bots for super high throughput short distances, especially in earlier nodes where I'm trying to saturate stupid quantities of e.g. iron, copper, or green circuit production. But each node doesn't have that much distance to cover, so there aren't that many belts relative to trains.
---
Construction bots though, obviously first priority. All my nodes get built by a special construction train that drops off supplies to a temporary construction stop, and then robots do all of the constructing of a node.
But its very weird and obscure. With such a lacking in space, you have to run multiple train types and overlap them: either having mixed trains. And there's also the issue of "leftover" pieces staying on a stack inserter (ex: Stack inserter grabs 7 items, but then the assembly machine only accepts 3 of them, so now the inserter is "deadlocked" with 4 items. But the assembly machine needs another item, so everything deadlocks and shuts down).
There's ways to fix all these problems of course.
--------------
But the easiest way is to instead use bots and/or belts to unload into the "last mile" going into the assembly machines. (Belt/bots can also reach 12 beacons per assembly machine if you're willing to have a faster, but more costly, design. Mainly for UPS wars rather than in-game benefits.)
But yeah, Trains are obviously the best bulk transfer item in the game. And while they aren't "unsuitable" for last-leg delivery per-assembly machine, its highly complex to do so. So its just easier to use belts/bots for that unless you're going crazy with UPS or something.
A great example of how omitting one factor can really change the qualitative behavior of your heuristic. I didn't know that the robot pathing to charging stations took into account queue length, since I was so used to seeing the infamous circles-of-depleted-robots queuing around roboports. Turns out they already had some smarts, but because the smarts omitted the (perhaps only in hindsight) metric of robots-heading-to-charge from the queue estimate, the practical effect it was trying to avoid (brigading around a single charging port) wasn't actually avoided.
On another side note, it's been a while since I've done the math, but it turns out that each roboport can only support about 50-100 robots. If you've got more logistics robots on a route than that, you need more roboports to keep the item flow up. If you don't have enough roboports, you're doomed to see throughput collapse as they're stuck in charging queues, although now I'm interested to start running tests to see how throughput is affected in such a degraded mode.
That's... a poor way of thinking about roboports IMO.
Roboports are specified with a charging speed: 4x ports of 1MW each. Robots have (3 kW static) + (5 kJ/m) power-usage. We can largely ignore the 3kW as a rounding error especially as infinite-research causes the distance based metric to dominate.
A Kilowatt is simply a kilojoule-per-second.
Rewriting the units: that means a Roboport's 4000kW of charging is: 4000kJ/s (or perhaps 4x1000kJ/s for the 4x ports), divide this out with 5kJ-per-meter for: (4x1000 kJ/s) / (5kJ/m) == 4x 200 m/s. Or 200-meters-per-second across 4 robots.
EDIT: I seem to have doubled up on the 4x multiple times in my first draft. Lets hope my revised math is correct now.
------------
That is to say, each Roboport provides 200-meters-per-second to 4x robots of charge.
Again: assuming the 3kW static is ignored. But you can consider "infinite research" to be the asymptote where you get closer-and-closer to this 800-meters-per-second aggregate limit of Roboport charging speeds.
-----------------
You can assume that at "maximum speeds", the dominant factor is charging speed. That is: all Robots have so much work to do that they're all "just" waiting to be charged by the roboports. Each Roboport provides additional charge of 200 meters-per-second aggregate movement to your worst-case robot network.
"Best case" is when your Roboports are _NOT_ the bottleneck (ie: Robots charge, then see that they have no tasks left to do and then start to sleep). In this case, additional roboports do nothing and instead its speed that dominates.
But we can see that in "busy" networks with thousands of items to move (ex: 8x train of 8000 green circuits per train == 64,000 circuits to move per delivery), its roboport-charge that dominates. You pretty much want to max out the density of Roboports and maximize the amount of charge you deliver to your robot network
----------
So its not that "Roboports support X number of Robots". Its that "Roboports support X-amount of robot travel distance per second".
The number of robots doesn't matter. The only thing that matters is how much the robots are moving.
Great game
