Fluid networks across games

In BuildCraft 2.2.4 a waterproof pipe stores its own liquid, in seven buffers: one at each of its six sides and one at its center. A buffer accepts liquid only up to a quarter bucket (250 units) plus its flow rate, 270 units in most pipes, and refuses a different liquid while it holds some. Each tick a buffer releases at most its flow rate, 20 units (80 in a golden pipe). Liquid waits in a delay line once after it arrives and again after it is released: written to the slot before the current tick's, it is read five ticks later (one tick later in a golden pipe). Liquid that came in by a side goes on to the center; the center hands it to the sides that lead out; and a side that leads out passes it into the next pipe or, when that pipe takes none, back to its own center, a side refused more than 20 times in a row being treated as an input. What nothing takes stays in the buffer for a later tick. So liquid crosses a line one pipe at a time, never faster than its pipes' flow rate. fluid-network/buildcraft-pipe-buffers

About: BuildCraft Fluid network

{
 "fillLimit": 270,
 "fillLimitGolden": 330,
 "flowRate": 20,
 "flowRateGolden": 80,
 "delayTicks": 5,
 "delayTicksGolden": 1
}

The delay: fill writes to slot (time − 1) mod travelDelay and update adds that slot to ready when time mod travelDelay comes round to it, five ticks later with six slots (one with two); empty does the same for out. The golden pipe sets travelDelay after the buffers are built, so its arrays keep six slots and use two. No pipe at this tag implements IPipeTransportLiquidsHook (L358), so every pipe fills through its side buffer. How many ticks liquid takes to cross one pipe wasn't measured. The center's split among outputs is buildcraft-pipe-split.

Cited by: Fluid network

In BuildCraft 2.2.4 a liquid pipe's center buffer divides what it releases among its outputs: the sides that the pipe leaves open (an iron pipe only the one it points to), that face a pipe or liquid container it connects to, and that liquid didn't come in by. Each output is offered an equal share, rounded up, until the amount runs out, in an order reshuffled every tick by 20 random swaps. If the outputs took less than all of it, the rest is offered once more, split among the outputs not marked full; the test that marks one full compares the total taken so far in the pass, not that output's own amount, with a share, so it can mark full an output that took its whole share and leave unmarked one that took none. A side counts as an input from when liquid enters by it until it has been empty for more than 20 ticks, and every side stops counting as one when the pipe has had no output for more than 20 ticks. fluid-network/buildcraft-pipe-split

About: BuildCraft Fluid network

With no output left unmarked, the second pass divides by zero in doubles; the cast gives a huge share but no side is offered it, so nothing happens. The shuffle is cached per world tick (lastSplit), so every liquid pipe uses the same order in one tick. Whether the marking test is meant to compare the output's own amount isn't stated in the code.

Cited by: Fluid network

BuildCraft 2.2.4 and Factorio before 2.0 both move liquid from pipe to pipe, and split it differently where pipes branch. A BuildCraft pipe offers its outputs equal shares, in an order it reshuffles every tick. In Factorio's old system, by Wube's FFF #416 (2024), the amount going to each side of a junction depended on the order the entities were built, as could a pipe's throughput. In the segment system the same post describes for 2.0, junctions don't matter: a segment answers only to the machines connected to it, each limited by how full the segment is, which the post says splits fluid much more evenly, though not perfectly. fluid-network/junction-splits-compared

Tier 2 because Factorio's side is Wube's description, not code. BuildCraft's even shares can still come out uneven when an output backs up (buildcraft-pipe-split).

Cited by: Fluid network