scottmsul
Joined 11 years ago
Joined 11 years ago
So much for "open" AI...
I wonder if this same approach could be used here in factorio? Using the pokemon red analogy the main "essential tasks" in Factorio are setting up automation for new items and new science packs. I think a good reward function could involve small rewards functions for production rates of each item/sec, medium rewards for setting up automation for new items, and big rewards for automating each new science pack.
Telling a Factorio agent to just "make a big factory" is like telling a pokemon red agent to just "beat the game", it has to be broken down into smaller steps with a very carefully tuned reward function.
Thinking about this is really making me want to jump into this project!
Counter-factuals like this don't apply when talking about average probabilities. If you cross over, it's an identical graph with identical probabilities. idk, to me it seems really counter-intuitive that the opposite bunk's node would be easier to get to than the current bunk's node.
For anyone who's interested, there's a group of us dedicated to natural myopia reduction at reducedlens.org, which is a free and open-source fork of endmyopia. I've even started measuring my axial length to try and get better data on if this stuff actually works (only one measurement so far though, so nothing interesting yet).
The nature paper was pretty crazy. Basically because blue bends more than red (think of a prism), it also focuses a bit sooner. This phenomenon is known as longitudinal chromatic aberration, or LCA for short. This means if you're myopic, blue might be more blurry than red, and vice-versa if you're hyperopic. The researchers in the nature paper had participants watch a movie where they straight-up blurred the blue or red with software, in order to produce fake LCA signals. They found the participants axial lengths still shortened or lengthened anyway in response.
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: https://github.com/scottmsul/FactorioQualityOptimizer
JS source: https://github.com/scottmsul/upcycle
JS app: https://scottmsul.github.io/upcycle