“Pipe blocked” usually means “no destination”, not “clogged”
The wiki defines flow as needing two conditions at once:
- An input building capable of receiving packets — pipe junction segments count.
- A pipe that can accept at least part of the packet.
Miss either one and nothing moves. The clearest illustration from the wiki: a pump connected to any number of pipes but nothing else will not pump. Conversely, “a vent connected to any number of pipes but nothing else will empty those pipes.”
So before you rebuild anything, ask one question: where does this packet end up? A full tank, a machine with a full internal buffer, and a vent in over-pressurised gas all look like “blocked” and all have the same cause.
Packets: one tile, one packet, one fluid
| Rule | Consequence |
|---|---|
| Each pipe tile holds only one packet | A pipe is a queue of discrete units, not a continuous volume |
| Each packet holds only one fluid type | Same-type packets can merge and “bypass”; mixed packets cannot |
| Mixing contents “drastically reduces throughput” | Filter contamination out at the source — for gases, mechanical filters at the input are strictly preferable to pipe filtering |
That merge rule is why two half-empty packets of the same water move fine, while a 5 kg water packet followed by an 8 kg polluted water packet “cannot merge” and the line crawls.
How much one line can actually carry
The pipe system updates once per second, and a packet moves one segment per update — so the segment capacity is the throughput ceiling.
| Per segment | Max throughput | Build cost | |
|---|---|---|---|
| Liquid Pipe | 10 kg | 10 kg/s | 100 kg (Plumbable or Metal Ore) |
| Gas Pipe | 1,000 g | 1 kg/s | 25 kg (Raw Mineral or Metal Ore) |
A liquid line moves 10× the mass of a gas line. That asymmetry is why gas networks sprawl and liquid networks rarely need to.
The number you can reuse for anything: divide the pipe limit by your machine’s output rate. The wiki’s own worked example — a Carbon Skimmer outputs a maximum of 1000 g/s (1 kg/s) of Polluted Water, so at most 10 can share a single Liquid Pipe or Liquid Vent without holdup. 11 or more requires two parallel pipes. Swap in your own building’s rate and the same division tells you when to add a second line.
Phase changes inside a pipe damage it (see the temperature guide for the thresholds). Prevent that by cutting the packet size to 1/10 — 1 kg for liquid pipes, 100 g for gas pipes.
Gas pipes have one convenience liquid pipes do not: they can share a tile with other buildings (just not another gas pipe).
Overpressure: the other reason nothing flows
A vent that cannot release is indistinguishable from a blocked pipe — the packet just sits there. Both vents have a hard ceiling:
| Vent | Overpressure limit | Build cost |
|---|---|---|
| Liquid Vent | 1,000 kg in the surrounding tile | 400 kg Metal Ore |
| Gas Vent | 2,000 g (2 kg) in its own tile | 50 kg Metal Ore |
| High Pressure Gas Vent | 10× the normal vent (≈20 kg) | Built from Plastic Gaskets |
Two details that explain intermittent behaviour: a Gas Vent “is affected only by the pressure in its own tile”, so in a tile holding several gases at different pressures it may release only intermittently, when low-pressure bubbles drift over it — clustering several vents together gives more chances to release. And there is no High Pressure Liquid Vent equivalent: the wiki notes “there is no Liquid Vent equivalent.”
(There is a well-known trick to exceed the 2 kg gas limit by standing the vent in a shallow puddle. The wiki classes it as an exploit, and it compresses gas without limit — worth knowing it exists so you do not think your build is broken, but do not build around it.)
Priority: the rule that fixes most junctions
This is the mechanic most players never learn, and it is why bridges behave strangely:
- The input node of a building (white symbol — bridge, vent, hydroponic plot) always takes priority if the building can accept a packet.
- The output node of a building (green symbol — bridge, pump, water sieve) always yields priority to any incoming pipe.
Worked example straight from the wiki: imagine two parallel pipe runs joined by a bridge from the upper to the lower.
- If liquid flows in the upper line but not the lower, the bridge takes all packets it can output.
- If both lines flow with full packets, the bridge does nothing — every time a packet is available for the bridge, a full packet already occupies the other side and takes precedence.
That second case is the classic “why is my bridge not working” moment. It is not broken; the far side simply keeps winning priority.
Junctions alternate, and that is usually not what you want
A junction made only of pipes runs round-robin: with three inputs and one output it takes one packet from each input in sequence; with three outputs it sends one packet to each in sequence. If one output backs up, the others receive more.
That is rarely the behaviour you actually want. Force direction by breaking continuous pipelines with bridges, valves and shutoffs, and keep “a simple, strict direction of flow, with all sources on one half of a pipeline and all consumers on the other.” Mixing sources and consumers on one line causes unpredictable path-finding where segments never fill and consumers get ignored entirely.
Two patterns that solve most problems
Overflow junction — you have more than enough supply and want the surplus diverted: Pipe the source directly to the overflow destination, then connect your main network to the source via a bridge. While the main network has demand, the bridge takes everything; once it is full the bridge blocks and surplus flows past.
Top-up junction — you have a preferred primary source and a backup: Feed the primary source directly into the network and the secondary source through a bridge, valve or shutoff. As long as the primary can satisfy demand, the bridge stays blocked and the backup is untouched.
Both work because of the priority rule above — the bridge is doing the deciding, not the pipes.
Configurations the wiki warns against
| Pattern | What goes wrong |
|---|---|
| Pipe running through consumers (hydroponic plots, vents, exo-suit docks) | Strict first-come-first-serve; early consumers starve later ones while filling large internal buffers |
| Pipe running through several outputs | Last-serve queue; middle outputs block because the building cannot output into a full or incompatible packet |
| Mixed contents in one line | Throughput collapse — filter early instead |
| Closed loop with no bridge | Will not fill and will not circulate |
A closed loop only works if you substitute one pipe tile with a bridge — that satisfies both flow conditions (a building output, a building input, and free pipe) and lets the loop accept and move packets. This is the basis of coolant loops and loop filters.
Keep some pipe empty and regulate output rates with automation rather than trying to run every segment full. See the automation guide for sensor-driven shutoffs — the wiki recommends shutoffs over valves, because valves are operated by dupes and keep pumping at the old rate until a dupe arrives to switch them.