A Lemmy community for the game Factorio made by Wube Software.
Do you think assemblers are for suckers? Do you want to pack everything into one assembler because that's just efficient? Well say no more fam I've got your back! The Chesterizer is the all in one solution for all your chest needs. Just set some values conveniently split across multiple locations and away it goes. It's like magic!
I used a blueprint because im real bad at platform design right now. Took me a few days to get the legendary stuff to build out the ship, and 12h travel time to get there.
I was a little let down there wasn’t anything at all, not even an Easter egg. But at least I did it!
The relatively long load times were starting to become a bother. I looked for some solutions online.
Boot up the game.
Hold down CTRL+ALT as you click on Settings button in main menu
You should see a new option labeled 'The rest' at the bottom.
Click on 'The rest' to bring up all the extra experimental settings.
The first setting is in "other settings" section, called
cache-prototype-data
Set it to true/click the box to toggle it on
The second setting is in " Graphics settings" section, called
cache-sprite-atlas
Note: The developers recommend turning sprite texture quality to normal/medium in regular graphics settings before enabling this. It will create a big multi gigabyte file on your computer.
Set it to true/click the box to toggle it on.
Watch the magic happen.
So I had a problem. I wanted to be able to broadcast a set of circuit signals representing a list of required items for a given outpost. The problem was that the radio only supports green and red channels leading to N>3 outputs intermixing signals.
Solution: Use a repeating clock that sends a signal only if Z={{my_chosen_channel_num}}. There's some odd stuff going on combinator wise to keep signal values in memory while the Z timer is on a different channel. Also requires a single clock radio blueprint in order to keep receivers and transmitters in-sync with one another.
This is my first time fiddling with circuits more advanced than if X > Y inserter_enabled so if you find a way to make this better LMK
If there's insufficient space around it, then it'll never spawn anything. This can be useful if you want to keep a specific spawner around for capture later but don't want too spend resources on killing the constant stream of biters.
75 tons was ridiculous and honestly we never should have released such a bulky monstrosity in the first place. The new Deliverator Slim is now a mere 73 tons!
Turns out the amount of water produced from melting ice is 20, and the amount of water needed for fuel and oxidizer is 10 each. So instead of cycling between fuel and oxidizer with a water override, we can just cycle to run one of each recipe. No storage tanks necessary!
R&D was also informed about a width issue with previous designs. With the removal of the water storage tank we were able to dramatically improve aerodynamics. For very brief periods of time while flying towards a planet, this sucker can hit 50km/s!
I've removed the self-sustaining ammo since it was just using up too many resources to be worth it for a small design. There were times where if it got low on ammo mid-flight it couldn't keep the engines on long enough to make up for being pulled into a planet's gravity due to the iron consumption. So I had to supplement it with ammo deliveries anyways, and I decided to just rely entirely on that. I also swapped out one of the solar panels for an accumulator and it seems to be working well.
The other main improvement is to the chem plant logic. It no longer needs buffers for the fuel and oxidizer. I use the on recipe complete signal to run a counter, mod by 2, then use that to flip between fuel and oxidizer. There is still a water tank to trigger a low water override.
If the chem plant is filled with too many resources it tries to run the recipes twice causing a lot of problems with the counting logic. Now the inserter is only active if the chem plant is not actively working which keeps it happy.
I noticed that when idling at a planet it backs up on fuel or oxidizer, clogs the pipe, then uselessly thrashes recipes. This creates an imbalance in how much fuel is available and while not proven I'm assuming it could create a condition where it can't use enough fuel to clear out the pipe and everything stalls. To prevent this I detect when I'm in orbit around a planet and stop producing fuel at that time. However I also realized if it somehow gets into orbit with a very low to zero amount of fuel that could prevent it from firing up again. So the orbit kill switch is hooked up to a timer and only disables the fuel/oxidizer production after 8 seconds.
I believe I could get the design down to 74 tons if I can figure out a consistently safe way to run the logic without the water tank, but 75 is such a nice number. I could also remove the accumulator but that causes worrisome power dips. The blinky lights are a core part of the ship's functionality and cannot be removed.
Part of our adventures making minimum viable transport ships. This thing barely works, moves slowly, can't fire at many asteroids, only sorta supplies enough energy. It gets where it needs to eventually though and includes the most important space ship feature: Blinky lights
I've been experimenting with using circuits to set recipes. This latest one was a lot of fun because it has to make water to feed back into itself for the other two recipes. The circuit logic is surprisingly simple with the new selector combinator and combinators being able to use red and green wire signals separately
