by Wiwiweb#7381, last verified valid for 0.6.113
The first few rockets you will launch will be manual. But eventually, you're going to want rockets to be sent without your help at all. Depending on what setup you want, this can range from very simple circuitry requiring no combinators, to very complex ones.
This guide assumes you are a circuit beginner, and will guide you through the steps by explaining how they work. The goal is to show you various rocket setups, but also to teach you a little more about Factorio circuitry.
Preparing the rocket
Regardless of what items you want in your rocket and what kind of logistic setup you want to design, first you need your rocket to be made.
Each rocket needs 1 Capsule, 100 Cargo rocket parts, and some rocket fuel (amount depends on destination). The rocket fuel can be filled with a pipe attached to any of the 8 connections of the rocket pad, and doesn't need any circuitry, so this guide will ignore it. The Capsule and Cargo rocket parts are inserted in the rocket like any assembler.
However, you can't simply put a requester chest and an inserter without any circuitry, because inserters will continue inserting even once the rocket is ready. They will start inserting capsules and rocket parts as part of your cargo!
To prevent this, the launch pad provides two signals indicating how many Capsules and Cargo rocket parts are in the rocket, including the ones used to prepare the rocket itself, and the ones in cargo.
Use each of these two signals with an inserter. One inserter to insert capsules, wired to work only when the rocket has less than 1 capsule. One inserter to insert parts, wired to work only when the rocket has less than 100 parts. See the picture on the right for an example.
Packed or unpacked rocket parts?
Note that instead of requesting cargo rocket parts directly, the setup on the right requests packed cargo rocket parts, and has an assembler to unpack them. This allows you to have 5 times fewer bot trips, which will save your bots from dying to attrition in the long run. If you prefer dealing in rocket parts directly, you can simply have 2 requester chests.
Capsules and Cargo rocket parts are well suited for bot transport, since they are required in very few quantities. If you use Packed cargo rocket parts, you can build an entire rocket with only 21 bot trips (1 for the capsule, 20 for the parts).
If you look at the bottom of your cargo rocket's inventory, you will notice that the last 2 slots are filtered to accept cargo parts and space capsules. No need to touch those! They are handled by SE automatically. These filtered slots ensure that your rocket can be built even if you completely fill your rocket with cargo. The filtered slots disappear once the rocket is ready so you can use the last 2 slots for more cargo.
Which rocket system to choose?
This guide will go over Single-item rockets and Multi-item rockets. Here is a quick comparison:
- + Very simple circuitry.
- + Can make N-to-N delivery systems easily.
- - Can only launch 500 stacks of an item at a time.
- - You will need at least 1 launch pad and landing pad for every type of item you request.
- - Big buffer sizes: Each landing pad will keep 500 stacks of an item. Good for raw resources but not for manufactured products (do you want 500 stacks of mining drills?)
- Common use case: Delivering raw resources created from outposts (e.g. ingots or plates).
- + More flexible.
- + Only buffer is 500 stacks for all items sent, not 500 stacks per item type. Convenient for expensive items or items you don't need that many of.
- - More complicated circuitry, and needs signal transmitters.
- - Only for 1-to-1 delivery.
- - Need to handle items running out before the next rocket is full (see "Multi-item rockets" below).
- Common use case: Resupplying outposts with complicated products (e.g. rocket parts, meteor ammo, or mall items).
Single-item rockets are very simple and don't need any more circuitry than what we already did to prepare the rocket.
Setting up your destination
Rocket launch pads are smart, and will wait for the target landing pad to empty before launching. Thanks to this, you can simply set your rocket to "Launch on Cargo Full", and you are done!
In addition, another very convenient thing you can do is to target "Any landing pad with name X". This can be used for N-to-N (multiple-launch-pads to multiple-landing-pads) delivery systems with no hassle.
By naming several landing pads the same name and targeting that name, your launch pad will launch to any empty landing pad. If there isn't any, it will wait. If several rockets are ready, and one landing pad becomes empty, one of the rockets will be chosen at random to deliver to it. This is similar to how you can name multiple train stations the same name to have a train go to "any free station", and if several trains are waiting only 1 train will go to a station with a train limit of 1.
If you need more of a resource, you can simply add a new launch pad. If you need the resources in a new place, you can simply add a landing pad.
For example, by making a rocket full of iron ore that targets any landing pad named "Iron Ore", you will be able to place a landing pad anywhere you need iron ore, without worrying about which rocket needs to go where. As soon as you rename your landing pad to "Iron Ore", a rocket will arrive to fill it. This is very powerful.
Taking care of the capsule and rocket parts at the destination
Your cargo will arrive at the destination mixed with any Cargo rocket parts that have survived (based on your re-usability tech) as well as the Capsule.
Make sure not to mix those with your cargo, by using filters (e.g. filter inserters, or filters on splitters).
Multi-item rockets (or "mixed" rockets)
The idea behind multi-item rockets is to check what you have at your destination, and fill the next rocket with what you are missing. This is a little more complex in terms of circuitry than single-item rockets, and needs signal transmitters. But compared to single-item rockets, it is more flexible and can let you have smaller buffer sizes than single-item rockets.
Destination circuit (Sending "What we need")
The first step is to figure out what your destination is missing. For this, the circuitry can be divided in 3 parts:
Request list ("What we want")
Use constant combinators to make a list of everything you want your destination to have in storage. A single constant combinator can only have 20 values, so you will likely need more than one. Just add up all their signals by wiring them all together.
Storage signal ("What we have")
We need a signal that contains all the things your destination already has. Most likely, that's going to be equal to the contents of your logistic network (Ctrl+L). Conveniently, a roboport can give out such a signal by checking the "Read logistic network contents" option.
Optional: If you are planning on sending logistic bots to replenish the bots lost to attrition, you may also want to check "Read robot statistics" and send a signal of "Logistic robot" for the "Total logistic bots" stat. This will add the logistic bots in your roboports as part of the "What we have" signal.
Optional: You can also wire non-logistic storage to add them to your "What we have" signal. Notably, it's a good idea to include the contents of the landing pad itself, in case it takes you a while to unload it into logistic storage. Otherwise, the next rocket might end up being filled with the things you just sent!
Once you have that signal, add a decider combinator to remove any negative values from it. You might think it's impossible to have negative values coming from your storage (How can you have -1 iron plates?) but it can actually happen in some cases which would cause you to request unexpected items.
Adding it up ("What we need")
We need to do "What we want" - "What we have" = "What we need"
First, turn the "What we have" signal negative using an arithmetic combinator that multiplies everything by -1.
Then, wire the result to the "What we want" signal to add them up.
Finally, add one last decider combinator to once again remove all the negative values. This is technically optional since the requester chest that will receive this signal already ignores negative signals. But it will make it much easier for you to see what is going on by removing all the useless signals and only showing what is actually being requested.
You have your final signal. Wire it up to a signal transmitter and also optionally to an electric pole for easy viewing.
If you've never used circuits before, please note that combinators have 2 sides where you can connect wires: The input side, and the output side. Make sure to connect wires to the correct side. If you connect both together, you'll create a loop which is useful for advanced circuitry but won't be used for this guide and will probably give you wild values. (Illustrated by DoshDoshington in 10 seconds)
Similarly to the destination circuit, we need to do: "What the destination needs" - "What the rocket has" = "What the rocket needs"
"What the destination needs" is simply the signal we sent out in the destination circuit. Put down a signal receiver, set it to the same channel, and make sure to use the same color of wire on it as you used for the signal transmitter.
"What the rocket has" can be taken from the rocket directly. Invert the signal with an arithmetic combinator.
Add together the two signals by wiring them together, and you've got a signal with everything the rocket needs.
The double-requests trap
The moment you launch a rocket, and for the ~23 seconds that a rocket takes to make it to its destination, your circuit will be thinking "the destination still needs a lot of stuff, and now the launch pad is empty, we should request everything", and suddenly your bots will start bringing everything you just sent off! And unfortunately, due to the way logistic bots work in Factorio, even after the rocket has arrived and the requests have been fixed, any bot already on the way will finish its trip.
To avoid this, let's make it so that we do not request anything when the rocket is not built. This isn't perfect, but with one fast inserter for cargo parts, it takes longer than 23 seconds to build the next rocket, so that is a simple way to pause the requests for a while.
Place down a final decider combinator that only passes on the "What the rocket needs" signal if the rocket is ready, which means, when the "rocket" signal is -1 (-1 instead of 1 because that signal has already been inverted by the arithmetic combinator earlier).
You can finally wire that to a requester chest in "Set requests" mode!
Dealing with item shortages when the next rocket is not full
In general, you want to fully fill a rocket before launching it, to avoid wasting rocket parts and fuel. However, with multi-item rockets, you might run into a situation where one type of item in your destination completely runs out, but your resupply rocket is not filled with 500 stacks yet.
There are a couple ways to work around that:
Request at least 500 stacks of each item type.
This is the simplest brute-force solution. It ensures that even if a single item runs out while all other items are filled, a new rocket will be ready and filled with that item. But it requires you to keep massive buffers of many items, which negates one of the major advantages of multi-item rockets over single-item rockets.
Adjust request amounts based on predictable consumption.
The idea is to have the contents of your rocket get consumed roughly equally. This is ideal in situations where you know exactly the ratio of resource consumption. For example, to resupply launch pads from outposts, you know that you will need 1 capsule for 20 packed cargo rocket parts, and the rocket fuel amount is also predictable.
For less certain consumption, you may want to manually increase requests via navsat when an item runs out. For example: "We ran out of vulcanite but the resupply rocket has 50 empty slots left, let's increase the vulcanite request count by 50 stacks". (Tip: Set a speaker to warn you when an item runs out, i.e. "what we want" equals "what we need".)
But for places with wildly unpredictable consumption rates (e.g. your space base running different types of science at different times) you might find yourself manually adjusting requests and unblocking rockets all the time, which is not ideal.
Force launch the rocket on green signal when any item runs out.
Instead of setting your rocket to "Launch on cargo full", set it to "Launch on cargo full or on green signal". Then, on the destination side, if any item is out ("what we want" equals "what we need"), send a green signal via the transmitter.
This ensures that you will never run out of any item, but you won't be using your rocket cargo capacity to its full extent.
Fill the rocket with commonly used items when any item runs out.
This is roughly the same idea as above, except instead of force-launching the rocket, you temporarily increase the request amounts so that the rocket is quickly filled. You could fill it with a commonly used item that you know for sure won't be a waste to send, or you could multiply all requests equally so that the rocket is filled with a roughly equal amount of all item types.
WIP These are bonus additions to your launch system. Circuitry won't be detailed, it is up to you!
More precise timer for request pause
In the "The double-requests trap" section, we disabled requests while the rocket is in flight, by stopping requests from being passed before the rocket was built. This works because building the rocket with one fast inserter takes longer than the 23 seconds of the rocket flight time.
We can instead set a circuitry timer for 24 seconds to more precisely pause requests. This also allows us to build the rocket a little faster, by using more than one fast inserter.
By counting the number of swings of the inserter bringing the capsules, and then keeping track of that count in a "memory cell" circuit, we can keep track of how many rockets each pad has launched. Then you could display this counter with a mod like Nixie Tubes.
Multi-item rockets with some items brought with belts
Sometimes you might have some item types used in much bigger quantities than your other requests. For example: Low density structures (for building scaffolding). To avoid bot attrition, it can be a good idea to bring these items via belt, while keeping the rest of your items requested by bot. Wire the inserter that brings items from the belt to be enabled only if the "what we need" count for this item is > 0. Then, use a "filter" combinator contraption to remove the request for this item before the signal is passed to the requester chest, to avoid bots also bringing that item to the chest.