We need to talk about the new fluid system

[sarge945]

I've seen this mentioned in several other threads, but I think it makes the most sense for it to be in it's own thread.

In general, the fluid system changes in Factorio 2.0 were quite positive, especially given how UPS intensive and janky/inconsistent the old fluid system was, so I am overall glad that fluids were changed, however at the same time I feel like the new fluid system has tipped things too far in the other direction, and has made handling fluids way too easy, normalizing long pipelines as the dominant strategy and invalidating fluid wagons. Barelling fluids was already a meme but now it's even worse. You can and should just use pipes for everything, always, as they have no drawbacks.

This is especially noticeable when compared to dealing with regular resources, where you CAN build long belts to and from each ore patch, however belts have very low throughput over long distances, biters are likely to attack and destroy them, and they are much much slower than trains. Faster belts are also significantly more expensive over distance compared to laying rail. At the same time, trains require a lot more infrastructure to work, and require wide turns, meaning belts are better for routing items around your factory and are much cheaper and more efficient for short distances, with trains being better for long distance travel. This is all good and works well, giving each option a viable use case, and gives the game depth because each of the transport methods have specific advantages and disadvantages, as well as costs associated with using them.

For Fluids, this isn't the case. Pipes have extremely high throughput (I have never ever hit the pipe throughput limit ever, I'm sure others have, but it's not common), are extremely cheap to build, are generally ignored by biters, and take up very little space. Pumps have a throughput limit, however this affects fluid wagons just as much as it affects pipes, and in either case the solution is simple, since pumps can be built in parallel.

Under the old fluid system, it was far less viable to build long fluid pipelines because it took a lot of time for fluids to travel around, and you'd often get weird bottlenecks in various places. Under the new system, fluid essentially travels instantly, in whatever quantities you can provide, with no drawbacks.

Not only does this solidify pipes as the dominant strategy and essentially invalidate fluid wagons (which don't offer instantaneous travel like pipes do, AND are limited by pump throughput at either end in a way pipes generally are not), but it also makes handling fluids extremely boring. Simply placing a pump every so often to prevent the pipeline from being too long doesn't really add anything in terms of gameplay, as pumps are cheap, will largely not affect your throughput in a meaningful way, and it's just annoying for barely any gameplay benefit. Placing pumps every so often amounts to busywork requiring no thought or tradeoff. There's no strategy around pump placement, it's simply a chore you must complete if you wish to have a long pipeline.

I feel like the new fluid system is too simple, and as a result, offers very little of value in terms of interesting gameplay.

There's many ways to balance pipes, some of which are better than others, and I really don't know what a good solution would be, hence this discussion thread.

Here are some ideas, from my least favourite to what I think is the best thing I could come up with:

1. Prevent pipes exceeding their extents entirely. This means removing the ability for pumps to allow you to extend pipelines. The advantage of this is that it would force players to use pipes for short distances only, and rely on fluid wagons for long distance travel. However, it's also overly restrictive, reduces a lot of player freedom, and generally would make things more annoying for everyone, so I don't recommend it.

2. Severely limit pipe throughput based on distance. This means, as your pipeline gets longer, your maximum throughput would decrease, which would be an abstract representation of your ability to pump liquids. This would mean that at a certain distance fluid wagons would offer better throughput overall, but it's somewhat of a boring system that is hard to understand for players.

3. Make pipes fill up slowly, over time, as liquids "slosh" around, taking longer as the pipeline gets longer. IIRC this was a feature of the old fluid system, although I can see it being very UPS heavy. This is similar to 2 in that is means that past a certain distance fluid wagons will be able to transport fluids faster than pipes.

None of these are particularly good ideas I'll admit, but I think SOMETHING needs to be done about the fluid system, because currently it lacks a lot of depth that was present before, and is extremely unbalanced overall.

When was the last time anyone seriously used a fluid wagon, especially in a large factory?

Remember when pipe throughput was important, so people recommended 1 pump to 20 boilers? None of that matters anymore.

I know the devs said that 2.1 was not going to add any new major features, however I believe the fluid system is unfinished and should use some refinement before 2.1 becomes official.

[Panzerknacker]

4. Completely revert to 1.1 fluid system

I foresaw all of this, warned, even spammed trying to prevent fluid change from being done. I still can't believe Kovarex actually let this happen. I tried Space Age but for me this change alone is so impactful that I went back to try 1.1 again and found it more fun to play, mainly due to the proper fluid system.

[Tertius]

In my opinion, the current fluid system is ok. It opens up more options in general than it closes. If, looking from the current state of the game, you restrict something, the impact of the limiting is more severe (removes more choices) than it opens up choices.

- The current behavior isn't too different to real world oil and gas pipelines which run over thousands of kilometers. Extremely high throughput, refresh station every few 100 km, ability to extract as much as has being input 2000 km away, all the time.

- If it comes to the 320 tile limit, I hit this limit with one of my Nauvis bases. It was the water pipe as far as I remember.
It also restricts the size of tileable nuclear reactors. Cannot be tiled infinitely without separating the water and steam pipes for each tile. That's a limit I don't like - I would be able to infinitely tile my nuclear reactor power plant blueprint, but I have to separate the fluid parts every 64 reactors. Not a real limit, but existing.
This limit is the only thing in Factorio that's felt as artificial limit just for the sake of game balance, not for making the simulation more realistic. However I'm unable to come up with a better solution that doesn't break everything else, so I accept it as it is. The real world doesn't have this restriction, so it's difficult to find a realistic balancing solution.

Because of the easy handling of fluid and gas instead of solid components, all the chemical industry processes in the real world deal with fluids and are made to turn everything into fluids/gas, then process, then retrieve any solid end product. Fluids are not unbalanced, it's how it works in the real world as well.

- Too simple ore mining: you still have to bring calcite to the outposts, and instead of a classic ore-to-buffer-chest and buffer-chest-to-train station setup you need a calcite unloading station, calcite belts, and a bunch of foundries next to the mining drills to produce molten metal. That's a definitely more sophisticated setup than a simple ore mining outpost that just transports away ore in cargo wagons. Instead of an ore unloading station, you have a calcite loading station, and you need pump stations and the infrastructure for supplying power to the pumps.

- The ability to use molten metal in a production base breaks the boring "main bus" paradigm. Instead of distributing vast belt lanes of plates and plate products, you just distribute molten metal and craft metal products on the spot where they are needed. This opens up variety vastly. Don't underestimate this - this is a completely different paradigm. If you grew up without foundries, it's possible you don't see what possibilities this will open up.

[sarge945]

The realism of piping fluid in real life isn't really relevant to game design. Fluids exist as a game mechanic, one which has been simplified over time, and is currently in a rather oversimplified state where the only real gameplay around the system is tedious pump placement, rather than anything interesting that requires the kind of problem solving that Factorio is built around (and what makes the game fun).

I don't agree that they should simply revert to the 1.1 fluid system wholesale, as it had it's own set of problems, which is why it was replaced in the first place, but in the name of fun (and not necessarily realism), I would appreciate a deep fluid system where managing fluid logistics is impactful and interesting and offers multiple strategies and options.

I suggested some ideas to that effect, which admittedly aren't great ideas, but I don't think "the real world works this way" is a good counterpoint.

I see your point though, using molten metals is definitely somewhat interesting compared to belts. It's just a shame that the rest of the fluid system is so boring. A lot of people's interactions with the fluid system are mostly going to revolve around their refinery, which has none of the interesting gameplay of molten metals.

If they wanted to go down the "build long pipelines" route, which is okay, then they should make that aspect of gameplay deeper. They can even do it in a realistic way if that's something you consider important - real life pipelines use extremely large pipes to move lots of fluid, which would necessitate multiple tiers of pipes, which could be balanced as a game mechanic - take the easy route by building large, resource-inefficient pipes, or risk congesting your train network by using cheaper fluid trains. Right now, pipes seem to be super cheap AND able to handle an insane amount of throughput, which is both extremely unrealistic and extremely boring.

4. Completely revert to 1.1 fluid system

I foresaw all of this, warned, even spammed trying to prevent fluid change from being done. I still can't believe Kovarex actually let this happen. I tried Space Age but for me this change alone is so impactful that I went back to try 1.1 again and found it more fun to play, mainly due to the proper fluid system.

We're never getting the old system back (for good reasons), but I am really hoping that at a bare minimum the fluid system can be opened up enough to allow modders to make it more interesting and closer to what was lost previously.


While this is not a complete solution, this mod is an example of the sort of gameplay that we SHOULD see with fluids - routing and distances should matter, and you should have to think about how you're routing fluids in ways that are very different to belts and solve unique problems. Currently fluids are completely braindead.

[GN89]

As a naive balancing solution, we could introduce a tiered pipeline hierarchy with layout limits to bring back logistics depth.

For example:
* Local Network Limit: A single local fluid system is restricted to a maximum of 128 standard pipes/tanks.
* Small Pumps as Internal Balancers: Small standard pumps no longer split the network. Instead, they sit inside the same 128-tile local segment, acting purely for internal fluid balancing and filtering.
* Main Pipelines: For long distances, players must use expensive "Main Pipes" (limited to 256 tiles per segment) and heavy-duty Main Pumps.
* Adapter Pumps: To bridge the gap, a special "Adapter Pump" would be required to connect a Main Pipe to a Local Pipe network.

This setup would completely separate local factory distribution from long-distance transport. It limits endless brainless pipeline laying while giving fluid wagons a highly competitive niche again for intermediate distances.

[sarge945]

As a naive balancing solution, we could introduce a tiered pipeline hierarchy with layout limits to bring back logistics depth.

For example:
* Local Network Limit: A single local fluid system is restricted to a maximum of 128 standard pipes/tanks.
* Small Pumps as Internal Balancers: Small standard pumps no longer split the network. Instead, they sit inside the same 128-tile local segment, acting purely for internal fluid balancing and filtering.
* Main Pipelines: For long distances, players must use expensive "Main Pipes" (limited to 256 tiles per segment) and heavy-duty Main Pumps.
* Adapter Pumps: To bridge the gap, a special "Adapter Pump" would be required to connect a Main Pipe to a Local Pipe network.

This setup would completely separate local factory distribution from long-distance transport. It limits endless brainless pipeline laying while giving fluid wagons a highly competitive niche again for intermediate distances.

Yeah this seems like a good way to handle it. It's still somewhat mindless on the smaller scale, but should be a lot more interesting for larger factories.

[GN89]

To expand on this, instead of standard underground pipes, we could design Elevated Main Pipes. They wouldn't be allowed to intersect with Elevated Rails, which would add a layer of logistical complexity.

[sarge945]

To expand on this, instead of standard underground pipes, we could design Elevated Main Pipes. They wouldn't be allowed to intersect with Elevated Rails, which would add a layer of logistical complexity.

I think you're onto something.

The old fluid system worked by making fluid itself complex to transport, but made pipes simple. Keeping the fluids simple and instead making the pipes complex seems like the right approach

[Panzerknacker]

hmm, im my opinion the old fluid system was simply a very elegant solution which naturally fit in with the game in almost every aspect.

I really believe we should try to improve upon that instead of taking the 2.0 system as a starting point.

Teleporting fluid is not cool.

EDIT
Tbh I think we need to first write down how exactly both system work, then like build some kind of pseudo-code version of them. Then we can start changing stuff and try to predict how it will affect the game.

[Harkonnen]

07-03-2026, 16-16-32.png (240.48 KiB) Viewed 749 times

[Harkonnen]

134574

My proposal from there:

One way to nerf it is to limit overall throughput of a pipe cluster to pumps to 1200 no matter how many pumps are attached to it, and spread it evenly between those. With that you will be forced to drag several distinct pipelines in parallel to get >1200 overall throughput. You will also be forced to separate them initially from pumpjacks which is a quest in itself. That of course should not affect pump-to-fluid-wagon - those will not be limited by this as well as other consumers (fluid tanks, machines).

[sarge945]

134574

My proposal from there:

One way to nerf it is to limit overall throughput of a pipe cluster to pumps to 1200 no matter how many pumps are attached to it, and spread it evenly between those. With that you will be forced to drag several distinct pipelines in parallel to get >1200 overall throughput. You will also be forced to separate them initially from pumpjacks which is a quest in itself. That of course should not affect pump-to-fluid-wagon - those will not be limited by this as well as other consumers (fluid tanks, machines).

This would be pretty cool too.

I think my favourite idea so far is the "Big pipeline with smaller pipelines coming off it, which are limited in length", especially if the big pipeline is expensive and has it's own limitations (like no undergrounds), so that fluid wagons are a viable alternative and running big pipelines requires careful planning and investment.

But your idea is good as well, it forces players to keep pipelines separate, and it's much much easier to implement than adding new pipes.

This actually reminds me of similar gameplay in Satisfactory, where you can unload a fluid wagon on a train nearly instantly, but the pipe connections can only move 60 fluid per second (or was it 600??) initially, and you get 2 of them, so you have to route them to your refinery separately and balance the throughput.

[GN89]

hmm, im my opinion the old fluid system was simply a very elegant solution which naturally fit in with the game in almost every aspect.

I really believe we should try to improve upon that instead of taking the 2.0 system as a starting point.

Teleporting fluid is not cool.

EDIT
Tbh I think we need to first write down how exactly both system work, then like build some kind of pseudo-code version of them. Then we can start changing stuff and try to predict how it will affect the game.

The problem with the 1.1 system is that its "elegance" came at a massive, unsustainable performance cost.

Under 1.1, every single pipe segment was treated as an independent fluid box. To simulate fluid flow, the engine had to calculate complex differential equations for pressure transfer across the entire map, which was incredibly CPU and memory intensive — a complete dealbreaker for the scale of the Space Age DLC.

Furthermore, the 1.1 system behaved unpredictably; fluid distribution at pipe intersections was non-intuitive and often depended arbitrarily on the build order of the individual pipes.

To put it into perspective: imagine a system with 2 tanks and 48 pipes connecting them.
* In 1.1: The engine had to perform 50 complex mathematical operations every single tick.
* In 2.0/2.1: This is resolved in a single operation, because the entire pipeline acts as a single, unified fluid network object under the hood, using much simpler math.

The 2.0 fluid overhaul was done primarily for UPS performance and secondarily to ensure consistent, predictable factory design. I completely agree that fluid logistics should be deeper and more challenging, but we must achieve that complexity through space and layout constraints, not by sacrificing the game's performance.

[GN89]

134574

My proposal from there:

One way to nerf it is to limit overall throughput of a pipe cluster to pumps to 1200 no matter how many pumps are attached to it, and spread it evenly between those. With that you will be forced to drag several distinct pipelines in parallel to get >1200 overall throughput. You will also be forced to separate them initially from pumpjacks which is a quest in itself. That of course should not affect pump-to-fluid-wagon - those will not be limited by this as well as other consumers (fluid tanks, machines).

While limiting cluster throughput to 1200 could work, it would require a significant rewrite of the fluid network logic under the hood to calculate these artificial caps.

The advantage of a tiered pipeline hierarchy (Local vs. Main Pipes with tile limits) is that the core fluid simulation code remains completely untouched. The engine still handles fluids as single, unified objects with near-instant distribution. We are only changing building limits and adding a few new prototypes, yet it brings a massive amount of logistical depth and balancing options.

The only real downside to the pipeline hierarchy approach is backward compatibility. Existing player factories and mega-bases would immediately break or lose throughput upon updating to the new limits, making old saves non-functional without a major redesign.

[sarge945]

hmm, im my opinion the old fluid system was simply a very elegant solution which naturally fit in with the game in almost every aspect.

I really believe we should try to improve upon that instead of taking the 2.0 system as a starting point.

Teleporting fluid is not cool.

EDIT
Tbh I think we need to first write down how exactly both system work, then like build some kind of pseudo-code version of them. Then we can start changing stuff and try to predict how it will affect the game.

The problem with the 1.1 system is that its "elegance" came at a massive, unsustainable performance cost.

Under 1.1, every single pipe segment was treated as an independent fluid box. To simulate fluid flow, the engine had to calculate complex differential equations for pressure transfer across the entire map, which was incredibly CPU and memory intensive — a complete dealbreaker for the scale of the Space Age DLC.

Furthermore, the 1.1 system behaved unpredictably; fluid distribution at pipe intersections was non-intuitive and often depended arbitrarily on the build order of the individual pipes.

To put it into perspective: imagine a system with 2 tanks and 48 pipes connecting them.
* In 1.1: The engine had to perform 50 complex mathematical operations every single tick.
* In 2.0/2.1: This is resolved in a single operation, because the entire pipeline acts as a single, unified fluid network object under the hood, using much simpler math.

The 2.0 fluid overhaul was done primarily for UPS performance and secondarily to ensure consistent, predictable factory design. I completely agree that fluid logistics should be deeper and more challenging, but we must achieve that complexity through space and layout constraints, not by sacrificing the game's performance.

I could not have put it better myself.

The 1.1 system was janky and half-broken, and I wouldn't want to reimplement it.

I wonder if it would be possible to fake some aspects of the 1.1 system using the new efficient 2.0 system. For instance, instead of doing complex calculations every update, they might be able to simply get the pipeline length, and then "fill it" over time with fluid based on a simple delay system (ie, it's 128 grid spaces in length, therefore fill it X percent per second). It's still calculated per-update, but it's a lot cheaper while being less accurate than the 1.1 system.

[Hurkyl]

Keep in mind that it's not like the devs never tried to implement a better fluid system.

Back in early access they were dropping teasers of a fluid rework that they wound up having to scrap because they couldn't iron out all of its problems (although they did backport the UI part of the rework into the old system)

And in the Space Age teasers they did mention that they had kept poking at it since then, but ultimately got to the point where the old system was stressed past its breaking point and didn't have a new system that was good enough to replace it. So they had to do something simpler.

[GN89]

hmm, im my opinion the old fluid system was simply a very elegant solution which naturally fit in with the game in almost every aspect.

I really believe we should try to improve upon that instead of taking the 2.0 system as a starting point.

Teleporting fluid is not cool.

EDIT
Tbh I think we need to first write down how exactly both system work, then like build some kind of pseudo-code version of them. Then we can start changing stuff and try to predict how it will affect the game.

The problem with the 1.1 system is that its "elegance" came at a massive, unsustainable performance cost.

Under 1.1, every single pipe segment was treated as an independent fluid box. To simulate fluid flow, the engine had to calculate complex differential equations for pressure transfer across the entire map, which was incredibly CPU and memory intensive — a complete dealbreaker for the scale of the Space Age DLC.

Furthermore, the 1.1 system behaved unpredictably; fluid distribution at pipe intersections was non-intuitive and often depended arbitrarily on the build order of the individual pipes.

To put it into perspective: imagine a system with 2 tanks and 48 pipes connecting them.
* In 1.1: The engine had to perform 50 complex mathematical operations every single tick.
* In 2.0/2.1: This is resolved in a single operation, because the entire pipeline acts as a single, unified fluid network object under the hood, using much simpler math.

The 2.0 fluid overhaul was done primarily for UPS performance and secondarily to ensure consistent, predictable factory design. I completely agree that fluid logistics should be deeper and more challenging, but we must achieve that complexity through space and layout constraints, not by sacrificing the game's performance.

I could not have put it better myself.

The 1.1 system was janky and half-broken, and I wouldn't want to reimplement it.

I wonder if it would be possible to fake some aspects of the 1.1 system using the new efficient 2.0 system. For instance, instead of doing complex calculations every update, they might be able to simply get the pipeline length, and then "fill it" over time with fluid based on a simple delay system (ie, it's 128 grid spaces in length, therefore fill it X percent per second). It's still calculated per-update, but it's a lot cheaper while being less accurate than the 1.1 system.

Regarding the length-based delay system or any per-pipe tracking: we have to consider how modern CPUs actually handle memory bandwidth.

Just to clarify, this is my own personal vision of how the fluid system might be structured under the hood based on standard optimization principles, rather than precise knowledge of the source code. But theoretically, right now, a fluid network of 128 connected pipe segments is treated by the engine as a single object, requiring just one operation and taking up one primary block of memory per tick. If we force the engine to track length, filling states, or custom delays for each individual pipe segment, we immediately multiply that by 128. Now, multiply that by the number of independent pipelines across a late-game factory.

Instead of 1 unified memory call, the CPU now has to perform 128 individual memory operations, dragging 128 separate values from RAM to the CPU cache. Modern processors are incredibly fast at raw math, but a mega-base engine will always hit a hard wall when it comes to RAM bandwidth (cache misses) if there are too many detached pipe networks tracking individual state data.

The tiered hierarchy with tile limits keeps the simulation "cheap" precisely because it limits building parameters at the layout level, keeping the underlying per-tick execution completely unified, flat, and lightweight for the memory controller.

[Hurkyl]

Remember when pipe throughput was important, so people recommended 1 pump to 20 boilers? None of that matters anymore.

As an aside, this is not a matter of pipe throughput: this is because the offshore pump creates 1200 water per second and boilers used to consume 60. The only impact old pipe throughput had on this was a limitation on how many pipe segments you could have between the offshore pump and your boilers and still get the full 1200 water/s throughput. Or complicating attempts to push multiple offshore pumps' worth of throughput through a single pipeline.

[sarge945]

Regarding the length-based delay system or any per-pipe tracking: we have to consider how modern CPUs actually handle memory bandwidth.

Just to clarify, this is my own personal vision of how the fluid system might be structured under the hood based on standard optimization principles, rather than precise knowledge of the source code. But theoretically, right now, a fluid network of 128 connected pipe segments is treated by the engine as a single object, requiring just one operation and taking up one primary block of memory per tick. If we force the engine to track length, filling states, or custom delays for each individual pipe segment, we immediately multiply that by 128. Now, multiply that by the number of independent pipelines across a late-game factory.

Instead of 1 unified memory call, the CPU now has to perform 128 individual memory operations, dragging 128 separate values from RAM to the CPU cache. Modern processors are incredibly fast at raw math, but a mega-base engine will always hit a hard wall when it comes to RAM bandwidth (cache misses) if there are too many detached pipe networks tracking individual state data.

The tiered hierarchy with tile limits keeps the simulation "cheap" precisely because it limits building parameters at the layout level, keeping the underlying per-tick execution completely unified, flat, and lightweight for the memory controller.

I was thinking more that the *entire pipe segment* would fill up as one single piece (and remain as an object), based on the length of the entire segment.

It's not super accurate of course, but it would keep the modern pipe-segments design while simulating "filling up" so to speak, simply by increasing the segments fill percentage over time.

But you're right, I don't really have an understanding of the source code here nor the intricacies of how this system works.

Remember when pipe throughput was important, so people recommended 1 pump to 20 boilers? None of that matters anymore.

As an aside, this is not a matter of pipe throughput: this is because the offshore pump creates 1200 water per second and boilers used to consume 60. The only impact old pipe throughput had on this was a limitation on how many pipe segments you could have between the offshore pump and your boilers and still get the full 1200 water/s throughput. Or complicating attempts to push multiple offshore pumps' worth of throughput through a single pipeline.

Oh that's right. It seems that a lot of things had their throughput increased, and IMO that's had a negative effect on the complexity and depth of the pipe system, but that seems like a separate issue to this one.

[Hurkyl]

I was thinking more that the *entire pipe segment* would fill up as one single piece (and remain as an object), based on the length of the entire segment.

It's not super accurate of course, but it would keep the modern pipe-segments design while simulating "filling up" so to speak, simply by increasing the segments fill percentage over time.

Isn't this part of the point of the throttling of fluid rates in/out of the network based on how full it is?

E.g. if a network is nearly empty, machines are supposed to only be able to take a fraction of the available machine<->pipe throughput, thus simulating the fact there would only be a trace of fluid at their intake.

I guess I've never tested the thresholds at which this mechanic actually has relevant impact. Maybe that needs to be tuned better?