Factorio Forums

Hurkyl wrote: Fri Jul 03, 2026 2:40 pm

sarge945 wrote: Fri Jul 03, 2026 2:38 pmI 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?

Yes, but it could be useful having it simulate distance travel as well. I think right now it's only based on the total amount of fluid being pumped into the pipeline, and no other factors.

For instance, if I connect a long pipeline to a tank full of oil, the entire pipeline will instantly fill up with oil, and a machine 300 units away can instantly start using that oil, it essentially teleports.

I propose that when it's connected, the entire pipeline fills up at a dynamic rate based on the distance it needs to travel, as a whole entity, without simulating individual pipe pieces - they would simply all fill up as one unit. It might take 2 seconds for the pipeline to "fill up" to 100% capacity from the tank, to simulate liquid pouring into and travelling along the new pipe.

It's kind of a bit weird and might feel bad to use, so maybe it's a terrible idea, but it at least would make things feel more like actual liquids.

Building upon @Hurkyl's point about throttling, a great way to handle pump mechanics without sacrificing performance is to make the pump speed dynamic instead of discrete.

Instead of a pump being binary (either pumping at 100% capacity or 0%), its throughput should scale smoothly based on the fill percentage of the input pipeline network. If the upstream pipe network is only 5% full, the pump dynamically throttles down and only pushes a fraction of its max rate.

This would naturally simulate fluid drag and drops in pressure over distance when supply is low, yet it remains incredibly cheap for the CPU because the pump only needs to check a single fill-state variable of the connected network object once per tick.

GN89 wrote: Fri Jul 03, 2026 2:50 pm Instead of a pump being binary (either pumping at 100% capacity or 0%), its throughput should scale smoothly based on the fill percentage of the input pipeline network. If the upstream pipe network is only 5% full, the pump dynamically throttles down and only pushes a fraction of its max rate.

I think that's also in there too; #430 describes throttling operations putting fluid into a network if they're near full.

Hurkyl wrote: Fri Jul 03, 2026 2:58 pm

GN89 wrote: Fri Jul 03, 2026 2:50 pm Instead of a pump being binary (either pumping at 100% capacity or 0%), its throughput should scale smoothly based on the fill percentage of the input pipeline network. If the upstream pipe network is only 5% full, the pump dynamically throttles down and only pushes a fraction of its max rate.

I think that's also in there too; #430 describes throttling operations putting fluid into a network if they're near full.

To clarify, I mean throttling based strictly on the pump's inlet network fill state, rather than the outlet.

If the inlet pipeline network isn't at 100% capacity, the pump's throughput shouldn't be at 100% either. For example:
* Above 90% fill: The pump works at max capacity (1200 fluid/sec).
* Below 10% fill: The pump drops to minimal fallback throughput (e.g., 120 fluid/sec).
* Between 10% and 90%: The pump's throughput scales dynamically and smoothly.

It makes perfect physical sense: it is naturally much easier for a pump to draw fluid from a completely full pipe than from a nearly empty one.

At the end of the day, these kinds of solutions don't simulate a true hydrodynamic fluid flow, but rather the inertia of the system. However, it creates a true physical bottleneck when the source network is starving, prevents downstream pumps from instantly "teleporting" trace amounts of fluid, and still keeps the C++ execution completely flat.

GN89 wrote: Fri Jul 03, 2026 3:20 pm

Hurkyl wrote: Fri Jul 03, 2026 2:58 pm

GN89 wrote: Fri Jul 03, 2026 2:50 pm Instead of a pump being binary (either pumping at 100% capacity or 0%), its throughput should scale smoothly based on the fill percentage of the input pipeline network. If the upstream pipe network is only 5% full, the pump dynamically throttles down and only pushes a fraction of its max rate.

I think that's also in there too; #430 describes throttling operations putting fluid into a network if they're near full.

To clarify, I mean throttling based strictly on the pump's inlet network fill state, rather than the outlet.

If the inlet pipeline network isn't at 100% capacity, the pump's throughput shouldn't be at 100% either. For example:
* Above 90% fill: The pump works at max capacity (1200 fluid/sec).
* Below 10% fill: The pump drops to minimal fallback throughput (e.g., 120 fluid/sec).
* Between 10% and 90%: The pump's throughput scales dynamically and smoothly.

It makes perfect physical sense: it is naturally much easier for a pump to draw fluid from a completely full pipe than from a nearly empty one.

At the end of the day, these kinds of solutions don't simulate a true hydrodynamic fluid flow, but rather the inertia of the system. However, it creates a true physical bottleneck when the source network is starving, prevents downstream pumps from instantly "teleporting" trace amounts of fluid, and still keeps the C++ execution completely flat.

By the way, with this logic, the pump would function very similarly to the Space Platform Thrusters, where throughput/thrust smoothly scales based on the available input buffers, keeping the simulation math predictable and unified.

GN89 wrote: Fri Jul 03, 2026 3:25 pm By the way, with this logic, the pump would function very similarly to the Space Platform Thrusters, where throughput/thrust smoothly scales based on the available input buffers, keeping the simulation math predictable and unified.

It's neat when one mechanic finds other uses elsewhere.

I think the puzzle design space with 2.0 fluids is more limited than I would like. The hardest part of any fluid puzzle is the routing of different fluid types without the pipes touching. While unintuitive, I found the throughput limitations pre-2.0 to result in some really compelling puzzle solving.

You will still have some throughput puzzles to solve for enormous builds that exceed that 320 tile limit. In reality though, most production blocks are less than 320 tiles which allows you to stack pumps in the space between. I find having to figure out how to squeeze pumps in between all your assemblers and beacons to be a much more rewarding puzzle.

Really, I think the issue is that the 320 limit is too high, so the pumps live outside the factory blocks instead of inside them.

Another throughput puzzle could be giving pipes a fixed throughput cap (just like belts). This cap is the maximum fluid that subscribers to the network can add/remove (higher cap with quality of course). This encourages you to run multiple lines of pipe for the same fluid just like real life. It also results in some really pretty builds and adds to the puzzle design space for mods.

GN89 wrote: Fri Jul 03, 2026 1:43 pm

Harkonnen wrote: Fri Jul 03, 2026 1:20 pm 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.

Not quite so, just one extra consumer (outgoing pumps), just with limited throughput. Also, in most cases graph of cluster-to-cluster connections through pumps will form a tree (or a forest), so there's just one single outgoing pump for each one. Rarely 2-3.

Another thing though is once I brought a fluid wagon from a very far away oil field to the edge of my base (even got Transfactorio achievemtn on that ) just to notice that I still need a pump to bring it it the other side of my base where refineries are placed, so I still had to drop a pump in between, and that was not a huge megabase. On that I'd say that max-distance should be x2 or x3 from what it is now.

It is only natural that everyone sees their own solution here. Some want to maximize UPS optimization while introducing a completely new layout mechanic, while others are willing to sacrifice a bit of performance to create a hybrid between the 1.1 and 2.0 fluid systems. Both ideas definitely have merit, and since I don't know the exact inner workings under the hood, I can only make assumptions based on general optimization principles.

Ultimately, my proposal is just an attempt to restore the value of fluid wagons without rewriting the current core simulation logic. It relies purely on geometric constraints (128 tiles including pumps for local networks, and 256 for main pipelines), dynamically scaling throughput for main pumps/adapters, and making main pipeline recipes expensive.

However, this idea does introduce some non-obvious behavior if we leave small pumps working with their current logic, as it splits the micro and macro management of local vs. main pipelines. In any case, the final word belongs to the developers, especially since they are currently busy reworking the system for EM-plant passthrough fluidboxes anyway(134309).

GN89 wrote: Sat Jul 04, 2026 5:47 am Ultimately, my proposal is just an attempt to restore the value of fluid wagons without rewriting the current core simulation logic. It relies purely on geometric constraints (128 tiles including pumps for local networks, and 256 for main pipelines), dynamically scaling throughput for main pumps/adapters, and making main pipeline recipes expensive.

That will just lead to long pipelines separated by pairs of static fluid wagon to bridge them, like players are using regular pump now. Just bulkier. And not actual moving fluid trains.

You need fluid wagons to mine uranium currently no ?

mmmPI wrote: Sat Jul 04, 2026 6:39 am

GN89 wrote: Sat Jul 04, 2026 5:47 am Ultimately, my proposal is just an attempt to restore the value of fluid wagons without rewriting the current core simulation logic. It relies purely on geometric constraints (128 tiles including pumps for local networks, and 256 for main pipelines), dynamically scaling throughput for main pumps/adapters, and making main pipeline recipes expensive.

That will just lead to long pipelines separated by pairs of static fluid wagon to bridge them, like players are using regular pump now. Just bulkier. And not actual moving fluid trains.

You need fluid wagons to mine uranium currently no ?

At the end of the day, Factorio is a sandbox game, and that's the beauty of it. Everyone is free to build their factory exactly how they like.

If someone actually prefers to place dozens of bulky, stationary fluid wagons on rails just to bridge pipe segments instead of running an automated moving train, that's their choice. You could theoretically build a factory without using standard pipes at all, relying only on pumps and static wagons.

GN89 wrote: Sat Jul 04, 2026 7:03 am At the end of the day, Factorio is a sandbox game, and that's the beauty of it. Everyone is free to build their factory exactly how they like.

If someone actually prefers to place dozens of bulky, stationary fluid wagons on rails just to bridge pipe segments instead of running an automated moving train, that's their choice. You could theoretically build a factory without using standard pipes at all, relying only on pumps and static wagons.

Yeah sure, but when talking about reviving the fluid wagon , i felt it's already alive , more often than not i see it used for bringing sulfuric acid to uranium mines, or for oil.

Then is if the idea is to prevent making long pipeline, you need to think of players that will "game" the restriction as best as they can lol, and i feel sometimes the solution appears worse than the problems they are meant to solve.

If the suggestion leads to some form of restriction for "pipe and pumps combined lengh" instead of "just pipes", it's "easy" to circumvent , and that unfortunatly i feel also applies for pipe hierarchies with "main" and "secondary" pipes , it would prevent fluid from "teleporting", to some extend, because every segment would require an additional tick to start moving fluid, but this sound almost like an attempt at reviving the old fluid system. The teleporting fluid part instead of individual pipes having their fluidbox is what allows the new system to be much more UPS friendly.

GN89 wrote: Sat Jul 04, 2026 7:03 am

mmmPI wrote: Sat Jul 04, 2026 6:39 am

GN89 wrote: Sat Jul 04, 2026 5:47 am Ultimately, my proposal is just an attempt to restore the value of fluid wagons without rewriting the current core simulation logic. It relies purely on geometric constraints (128 tiles including pumps for local networks, and 256 for main pipelines), dynamically scaling throughput for main pumps/adapters, and making main pipeline recipes expensive.

That will just lead to long pipelines separated by pairs of static fluid wagon to bridge them, like players are using regular pump now. Just bulkier. And not actual moving fluid trains.

You need fluid wagons to mine uranium currently no ?

At the end of the day, Factorio is a sandbox game, and that's the beauty of it. Everyone is free to build their factory exactly how they like.

If someone actually prefers to place dozens of bulky, stationary fluid wagons on rails just to bridge pipe segments instead of running an automated moving train, that's their choice. You could theoretically build a factory without using standard pipes at all, relying only on pumps and static wagons.

True, but at the same time, it's still a game with objectives and dominant strategies (which is what this thread was specifically created to fix - a dominant strategy).

Even in a sandbox game, ideally all options would be equally interesting and offer their own advantages and trade-offs, as this gives the logical problem solving more depth and allows the sandbox to operate based on consistent rules.

At the end of the day, the aim of the game is to build an efficient factory that can produce enough resources quickly enough to win the game. If one strategy is clearly better than the rest, then while you CAN do other things, you're heavily incentivised not to.

sarge945 wrote: Sat Jul 04, 2026 7:27 am True, but at the same time, it's still a game with objectives and dominant strategies (which is what this thread was specifically created to fix - a dominant strategy).

You don't use fluid wagons for oil or uranium mining ? because really the premise that there is a problem with fluid wagon can be discussed lol.

Just to clarify, I think some of you are misunderstanding my point. I actually really like the new 2.0 fluid mechanics and fully support the change. The near-instant distribution within a cluster is brilliant and essential for maintaining high UPS at scale. I am absolutely not advocating for a return to the 1.1 per-pipe logic.

My proposal was purely a conceptual response to @sarge945's original complaint about long-distance fluid transport losing its logistical depth. It was a thought experiment on how we could reintroduce complexity and give fluid wagons a viable niche on macro-distances using layout constraints (like the 128/256 tile limits) and dynamic adapter pump mechanics.

The core goal of my idea was to achieve that balancing effect while remaining 100% UPS-friendly. The internal fluid simulation would stay flat, unified, and instant, without calculating individual segments or adding per-tick network delays. It was simply an attempt to find a middle ground where logistics remain challenging, but mega-base performance is preserved.

mmmPI wrote: Sat Jul 04, 2026 7:29 am

sarge945 wrote: Sat Jul 04, 2026 7:27 am True, but at the same time, it's still a game with objectives and dominant strategies (which is what this thread was specifically created to fix - a dominant strategy).

You don't use fluid wagons for oil or uranium mining ? because really the premise that there is a problem with fluid wagon can be discussed lol.

Personally, I haul everything over long distances using trains simply because I am a huge rail network enthusiast.

GN89 wrote: Sat Jul 04, 2026 7:40 am Personally, I haul everything over long distances using trains simply because I am a huge rail network enthusiast.

Me too ! hehe i like railworlds so more often than not i will use train wagons for oil and sulfuric acid on Nauvis, which is easier when you already have the rails infrastructure around.

The only "super long dumb pipes" i found myself using out of lazyness were on Vulcanus, for the sulfuric acid, before i had the rails layout for tungsten, when i didn't realize how much i would consume from the geysers and didn't build the consumers next to the source when i could upon arrival. And also on Aquilo, because it is easier to add super long pipes above ice platform than to ship the whole train network stuff if you are not into a super long game i found.

That is somewhat different than the behavior of steam in large nuclear power plant, or steam engine power plant where there could have been many "fluid junctions" whose distribution logic was difficult to understand. The new fluid system adresses that.

What i find somewhat cursed is the very long pipe of molten iron, made of iron, on the planet where you have tungsten, it should have been used for tungsten pipes, but that's not really something i can blame on the new fluid system.

I wonder if it would be possible to have some kind of hybrid system.

I'm thinking of a system like in 1.1 but instead of calculating every pipe segment individually we would treat long end-to-end sections of pipe as one huge segment but somehow with the same flowrate properties as the section would have with the old system. The flowrate characteristics would need to be simulated/calculated only once upon building the pipeline and stored in a formula.

When connecting another pipe to the section somewhere in the middle the section would automatically be split up into two and the calculations redone.

If possible somehow, this would speed up calculations dramatically by only having them be done where it actually matters.

I guess we would need access to the source code to really be able to tell.

mmmPI wrote: Sat Jul 04, 2026 7:29 am You don't use fluid wagons for oil or uranium mining ? because really the premise that there is a problem with fluid wagon can be discussed lol.

Nope. I use the far more effective strategy of barreling it and then transferring it over using logistics bots.

Or even better, just place your cargo landing pad next to your uranium mine, then you can use rockets to transfer the barreled fluid to your uranium mine via a space platform, saving you the trouble of using bots AND wagons!

Actually seriously though, I wouldn't say fluid wagons are completely 100% useless in all cases. But they are extremely niche, and I can see piping fluids like that being more effective in a significant number of situations rather than using the wagons. They are very disappointing in just how little use they have.

sarge945 wrote: Sat Jul 04, 2026 9:00 am

mmmPI wrote: Sat Jul 04, 2026 7:29 am You don't use fluid wagons for oil or uranium mining ? because really the premise that there is a problem with fluid wagon can be discussed lol.

Nope. I use the far more effective strategy of barreling it and then transferring it over using logistics bots.

Or even better, just place your cargo landing pad next to your uranium mine, then you can use rockets to transfer the barreled fluid to your uranium mine via a space platform, saving you the trouble of using bots AND wagons!

Actually seriously though, I wouldn't say fluid wagons are completely 100% useless in all cases. But they are extremely niche, and I can see piping fluids like that being more effective in a significant number of situations rather than using the wagons. They are very disappointing in just how little use they have.

Haha, using space platforms and interplanetary rockets just to bypass fluid wagons for a local uranium mine is peak Factorio engineering!

Before 2.0, I used to balance my oil refineries using complex circuit networks with full and empty barrels.