Priorities
I must admit it's pretty weird to make the claim that I'm an "expert" at certain games.
I'm...
- A Master League Starcraft 2 player.
- Really good at WOW... I guess?
- A former professional poker player.
- Pretty good at Go and pretty bad at Chess given time spent playing.
- Good at building complex Redstone devices in Minecraft.
- Well learned in crypto, decentralization, and DLT.
- Slacking as a developer/programmer.
And now... this.
If I'm being honest it's actually kind of annoying that I'm not better at chess considering how much time I've spent playing it over the last 5 years. Obviously I could crush any random who doesn't play, but on the competitive level my ELO never really seems to go up. Always stuck in the slightly-above-average rangebound. But I digress.
The level of complexity in this Factorio game is actually quite staggering.
The screenshot above is a circuit I built to dynamically restock my outlying bases on other planets. When they run out of critical asset the circuits broadcast a signal to the blue 'requestor chest' which will in turn signal a logistics robot to pickup that item and drop it in the box, which in turn gets loaded onto a cargo rocket that launches in big batches of 500 stacks of items when full. The overhead cost of this solution can be a bit high due to the volume required but it's also quite cheap and scalable as long as I'm not blasting too many rockets outside of my own solar system.
The sheer size and scale of the Space Exploration mod is really quite something. It's a miracle this version of the game even runs on older computers. Not only that, it runs quite well. Although the size of my game is approaching 200MB, but there are ways to 'trim' that down.
By my count there are 20 star systems and several deep-space asteroid fields. Each star system has around 20+ planets/moons/asteroid-belts so there's at least 400 places one could choose to setup a base. Of course there are many reasons to pick a certain location, from resources at the location to the size of the sphere to the hazards on the surface (no water, meteors, and hostile alien bugs). There are also tradeoffs: a bigger planet has more resources but also has a higher gravity and require a lot more rocket fuel to launch rockets from the surface.
https://www.reddit.com/r/factorio/comments/jki8go/circuitcombinator_tutorial_for_space_exploration/
I'm particularly pleased with my own solution to this problem, because it's much better than the one posted online through reddit. In my solution the green wire is what you have and the red wire is what you want. The green wire is substracted from the red wire to broadcast the request signal. I actually didn't even know requestor chests could dynamically change their signal based on circuits until a couple of weeks ago so this project ended up being a pretty satisfying victory and pretty useful. It's a much more scalable and modular solution than manually setting it up and holding items in reserve.
The reddit solution to this problem is extremely convoluted to the point of me not even being able to figure out when the author is even thinking. I'm guessing he didn't know you can just splice the two signals together to get the desired outcome which is why this post has so many circuit gymnastics. Looking at the comments pretty much everyone seems to think this is a good way of doing it and they even copy the blueprint for their own bases. So again I'm particularly proud of the solution I've found even though it's so niche no one else will ever appreciate it.
Blacklist Sortation
Another trick I've learned is the ability to create a sortation center that has infinite modularity and scalability based on blacklists. Using a blacklist is very uncommon, with the whitelist being the standard. Normally a player would tell the game which products they want their inserters to grab. Instead what I've done here is tell the inserters which items not to grab, which leaves those particular assets all sitting in the chest they are pointed toward.
This strategy as allowed me to store 3 items in every warehouse as the grid moves south. If I need more room for a particular asset I build overflow protection to the west. This allows me to add extra items (south) or add extra storage (west) at any time without having to modify any of the current infrastructure, which is a big win compared to how I used to do things before. The modular solution wins.
The one limitation of this strategy is the throughput of the six stack-filter-inserters that push items to the south. Every item that gets deposited to the Orbital Command landing pad (this base is in orbit above my starting planet Nauvis) must get filtered through these six inserters multiple times to get where it needs to go.
The rotation speed of these inserters is 864 degrees per second. Divided by 360 is 2.4 transfers per second. When I first build this solution each stack inserter could grab 8 units at a time, but now I've since upgraded that to 12 through advanced research. That's 172.8 items per second (12 x 2.4 x 6) which is quite a bit considering that belts only transfer a maximum of 45 per second. Also, any item that ends up having massive volume and clogs up the system can just get a dedicated landing pad to circumvent any potential bottlenecks. I also just remembered that I've recently researched advanced stack inserters (KR mod) which have 50% more rotational speed which would increase the throughput of this sort center to 259.2 items per second, which isn't necessary but I might do it anyway because it would be trivially inexpensive to do. In fact I just did it now with a single swipe of my mouse.
red wire controls overflow protection; green wire is master line
SOP Standard Operating Procedure.
There are many tactics I employ in this game that are definitely not required but tend to result in less critical errors that need fixing. This is a common theme within the corporate world as well. Programmers often write code in a similar format so that upkeep and upgrades are easier to perform when someone else is working on code they didn't write themselves. This type of homogony results in more modular and scalable system (hopefully).
For example when I see a green wire I can be reasonably sure that this is my master line that adds up all the items of note on a particular planet or surface. Red wires are more localized to solve specific problems. I also use red wires on spaceships for the output and the contents of the ship, with the green wire being the input (speed/destination/launch signals). Little things like this make things less messy and easier to deal with when things go wrong, and more importantly they prevent things from getting worse when you 'fix' them or breaking another part of the game. Again, many of these strats are particularly relevant to actual computer programming.
Signals: ANY / EVERY / EACH
After over 2000 hours played I finally recently figured out there are some very useful generic signals used in building logical circuits.
Everything
The red star is the everything signal. If I said everything > 500 then all signals must be greater than 500 for the output to be true and broadcasted. However, if there are zero signals then it is assumed that everything is true, which is confusing but makes sense once you actually use it a few times.
Anything
The green star is the anything signal. If I said anything > 500 then only 1 signal needs to be higher than 500 for a true output. However, again this gets confusing because if there are no signals it is assumed anything is false by default. This got me into trouble when I created a generic overflow protection circuit. The logic states anything < 1000 and the true signal activates a belt that refills the depleting warehouse. However, if the depleted warehouse in question actually gets to 0 items: the circuit flips false and cuts off assess to my reserves; breaking the intended logic.
Wut?
Why would anything be false on an empty signal and everything be true on an empty signal? Honestly I only understand it just well enough to use it for myself rather than trying to explain it to someone else. I guess if I had to try I'd say that a signal of 0 is no signal, which means nothing; so anything would be false.
Getting no signal vs broadcasting a hundred signals with a zero value is the exact same outcome in this game. If machine code is zero or one on a transistor, the zero just means zero electricity (off), so it's just a placeholder and there's nothing actually there. On the flip side it must be assumed that everything > 500 given no signals at all because there is no signal available to contradict this logic. It's confusing for sure but slowly starts making sense when you actually start tinkering with these systems.
Another way of explaining it would be that the everything signal looks for a signal that will contradict the logic, so no signal means no contradiction, and is thus true. Meanwhile, the any signal looks for a signal that will prove it true, so no signal means it wasn't proven true and is thus false.
Each
The each signal is the closest thing this game has to a for-loop in programming. If we set an arithmetic combinator to each + 5 it will take each signal and add five to it in the output. This is definitely the easiest special signal to understand, but can be tricky to get the intended results without the ability to use classic object-oriented programming.
Much like Minecraft Redstone logic, Factorio circuit logic is a lot like programming in assembler code with only half of a toolkit. There are a lot of limitations on what one can actually do, presumably to keep the game from becoming laggy and completely unplayable. However it's pretty interesting what is actually possible, as even Minecraft players have created unbelievable builds (like a full-on virtual computer). Factorio circuit logic is much much more complex than Minecraft redstone, so there's even more one can do in this game.
There are even little known arithmetic operations available such as modulus (%), XOR latch, and even bit shift left (<<) and bit shift right (>>), which is pretty insane for a video game.
A few more things to talk about.
Trying to wrap this up... looks like I still have trains, snap to grid, and wifi to chat about. Time for a speedrun.
Snap to grid
This is another feature of blueprints I had no idea that existed until now. You can set up blueprints in such a way that you can click and drag them across the map while having them remain perfectly tiled to later be created by construction bots. Without snap-to-grid the player has to carefully place every blueprint individually which is much more time consuming given a blueprint that gets used over and over again (like in this case power and solar panel fields).
There are several options to fool around with including absolute vs relative, width & height, + X & Y offsets. Absolute snaps to a default global grid that invisibly exists on the planet surface while relative can be placed anywhere at first and then lines up during the click & drag. I use relative for everything now but absolute is pretty convenient for huge blueprints that hard to line up manually, as there will never be a misclick with absolute.
Size of the blueprint grid and associated offsets are useful for various custom alignments (like making sure roboports and power-poles on the edge of the blueprint aren't constructed twice right next to each other).
Yes indeed I did create an x-wing style spaceship.
Logistics as a WIFI network.
Another trick I learned a while back is that a wire can be connected to a logistics roboport and the resulting signal will be every item the bots have access to, which is pretty useful for advanced builds. Roboports create a wifi logistics grid in which items can be transferred by air instead of with belts and trains. The limitation being power and the ability to recharge them quickly enough so that they don't stack up at the charging ports (4 per roboport).
Trainyard
I really wanted to create a massive train network in this game, and I seem to have succeeded. I use very basic rules for my trains to make sure problems and traffic jams occur infrequently. All turns and junctions are roundabouts, and all directions are one-way only, which requires twice as much track but ends up solving a myriad of problems and jam-ups. This is the scalable and modular solution, as track can be used to transport a near infinite amount of product across using trains powered by cheap solid fuel. I resolved to use diagonal track as little as possible which has resulted in clean square grids I could build in the center of, so it all worked out quite nicely.
Conclusion
My SE-KR Factorio game is one of the most complex simulations I will ever create. It's been fun but has really left me wanting to do something more productive (like actual programming and building on Hive). Luckily I'm getting close to the end and I have no intention of making another game after this one... probably ever. The burnout is real.
However it has been nice because some of the lessons I've learned in this game absolutely do apply to the real world and other digital ecosystems. Sometimes I'll just be driving down the road thinking about the roads and traffic lights as if they were the train signals I had just built earlier in the day. Real nerd stuff I know.
So yeah I guess I'm a Factorio expert now!
I've done all the things!
Cheers!
Wen moon?