Oh boy, this is a rabbit hole I've gone down pretty hard as well. I made a python script and a separate js app for running linear solvers on the upcycling problem. I really like the author's exposition for how to setup the solve matrix, as it's the first step when understanding the quality math.
Speaking very high level, probably the most interesting and counter-intuitive thing I learned from doing these projects is that adding just a touch of speed modules can go a long way, especially at the lower quality levels. Of course, if the only thing being optimized is legendary outputs per common input, then speed is always bad. But because an upcycler works much better when the buildings and modules are themselves legendary, usually the limiting factor is the (very expensive) crafting machines, rather than the amount of input lines. Adding a touch of speed can give way more throughput for the same number of legendary crafting machines, at the cost of some wasted inputs, which isn't a big deal when you can slap down a few more cheap miners.
Yeah same! I had this essentially same writeup in drafts for my blog, and got distracted by ... factorio ... and never finished it. Glad to see the direction and findings confirmed. Excellent writeup.
Sadly, the specter of maintenance is omitted from Factorio, and acts as a limiting factor on automation in the real world...
When all of your factory bits are randomly wearing down, causing speed mismatches and stochastic outright failures, large and complex chains become limited by your ability to run around and diagnose and fix things. Things also tend to fail in novel and unexpected ways; redesigns can help mitigate some failures, while new failures may be introduced. And as reliability improves, you start seeing failures that occur on longer timescales, which more trivial failures would initially mask.
scottmsul · · focus · HN ↗
Speaking very high level, probably the most interesting and counter-intuitive thing I learned from doing these projects is that adding just a touch of speed modules can go a long way, especially at the lower quality levels. Of course, if the only thing being optimized is legendary outputs per common input, then speed is always bad. But because an upcycler works much better when the buildings and modules are themselves legendary, usually the limiting factor is the (very expensive) crafting machines, rather than the amount of input lines. Adding a touch of speed can give way more throughput for the same number of legendary crafting machines, at the cost of some wasted inputs, which isn't a big deal when you can slap down a few more cheap miners.
Python script: <a href="https://github.com/scottmsul/FactorioQualityOptimizer" rel="nofollow">https://github.com/scottmsul/FactorioQualityOptimizer
JS source: <a href="https://github.com/scottmsul/upcycle" rel="nofollow">https://github.com/scottmsul/upcycle
JS app: <a href="https://scottmsul.github.io/upcycle" rel="nofollow">https://scottmsul.github.io/upcycle
jvanderbot · · focus · HN ↗
delichon · · focus · HN ↗
If the boffin head-space consumed by Factorio never happened, we may have been building factories on distant planets by now.
sdenton4 · · focus · HN ↗
When all of your factory bits are randomly wearing down, causing speed mismatches and stochastic outright failures, large and complex chains become limited by your ability to run around and diagnose and fix things. Things also tend to fail in novel and unexpected ways; redesigns can help mitigate some failures, while new failures may be introduced. And as reliability improves, you start seeing failures that occur on longer timescales, which more trivial failures would initially mask.
delichon · · focus · HN ↗