Friday Facts #416 - Fluids 2.0

[MeduSalem]

But I dunno if today's CPUs really have "spare transistors" per se. They are vastly over provisioned with tools and gadgets for what they can do, but are constrained by a heat/electricity budget instead.

Well, the Out-of-Order engine of CPUs are designed to fill up the pipeline & keep Execution Units busy to crank out the highest IPC possible. It will always try to execute something with the execution resources it has... if it can.

What CPUs are rather doing to prevent the power consumption & heat development of cores to get out of hand is toy around with the voltage & frequencies.
Because with that you can save power consumption in a squared fashion. So inherently there are more power savings gains there.

You are usually better off trying to keep more of CPU core's execution units occupied. The power consumption from using more execution units only scales in a linear fashion rather than in a quadratic fashion.
With other words you could hypothetically get more done for the same amount of power invested than if the CPU tries to maintain higher voltages & frequencies to do the same in serial fashion on a lesser amount of execution units.


So if you never use Float or if you never use Integer instructions you are kinda wasting potential performance regardless.

I mean, in principle the CPU core will look ahead and look if there is something it could potentially do. But the out of order window is usually limited. If the distribution of Ints/floats is very one sided for a long time, it potentially screws the performance because it could have higher IPC but the program just doesn't let it exploit that.

[o6dukeleto]

In general, the proposed solution would likely make storage tanks (except maybe for circuit network signals), pumps and fluid train cars almost obsolete if you are optimizing fluids.

Remember, the point of Trains is not that you get more Fluid throughput, its so your Base is more modular and you dont need to put extra effort into laying a pipe in the middle of nowhere, since you can just reuse your Cargo Train Network. The CURRENT Fluid system is perfectly fine for Oil and Acid pipelines like yours, and people still use Trains for their OTHER benefits, so do not call them obsolete for no reason.

And a Storage Tank with a Pump leading into your Consumer Pipe will make a LOT of sense now, since the Pump when paired with a Tank will allow for a higher rate than the Tank alone. This is likely one of those hidden NEW emerging mechanics that the Devs mentioned in the FFF!

Once again I disagree.

A train network and train has to be modified every time you want to deliver/collect fluid to/from a new location. That new location needs new pipe infrastructure BUT to support trains it will also need more infrastructure to support the fluid train car, so why make things more complex. Just add a few pipes to deliver/collect to/from the new location and ignore all the train "complexities." It might be more fun with the train stuff, but I suspect it will be much easier and less time consuming to just add a few pipes.

The real reason for the train network is that "scales up" very easily over long distances. A train network can deliver the equivalent of many many blue belts as time goes on --- depending upon train length and number of stations. Nothing is faster over long distances and large volumes.

EXCEPT

The proposed pipe changes under fluid 2.0, a single pipe segment scales up even faster than the train network. You don't need multiple belts or multiple trains or multiple stations, you just need one pipe segment.

Adding pumps to your fluid network is also counter optimal -- having a single segment will be instant -- pumps are slow when compared to that even if they are attached to tanks. Since pumps are not really needed -- storage tank usefulness is limited to adding segment volume AND as signal point for a circuit network

Basically the proposed solution for fluids 2.0 is almost exactly the same as the power network in factorio, except the pipe segment will have to fill up before it is optimal.

There might some edge cases where pumps and fluid cars still make sense, ("almost" obsolete), but they will be minimized.

[YakigatoNiji]

I was looking at people's concerns with the new fluid system, and I agree that this new solution feels... wrong. While the previous solution was definitely janky, the fact that once your production reaches a certain level, you can just to turn everything into enormous pipelines and call it a day makes this new solution boring to me. In terms of game mechanics, it feels like we're just solving the same problem as electricity.

I wonder if the key isn't to decouple volume from pressure and stop thinking about everything in term of volume and throughput. This is closer to how the real world behave, while also being gamified enough to not require solving maxwell's fluid equations just to move gases around. Most importantly, it feels different from other mechanics in the game. Electricity works in term of balancing production and cusumption, while fitting distribution in the space you have. Items works in term of quantities over time, and moving them to the correct destinations fast enough. With the idea of pressure, fluids becomes about balancing volume with pressure. You need enough flow to craft, which high pressure will give you, but high pressure will "break" machines, so you can't go too high. On the other hand, too low pressure won't give you enough flow, and your machines will stay idle most of the time! A whole new class of problems to solve in the game!

Here's a few ideas of what that might look like in game. First, we start with your new solution which is great to deal with the volume problem. Then, we add a new property to fluids: pressure. Just like temperature, some machine requires a certain pressure to work. You can't feed cold water from an Offshore Pump to a Steam Engine. You can't feed 5 PSI crude from a Pumpjack to an Oil Refinery. You can raise temperature with a Boiler between your water source and your engine. You can raise pressure with a Pump between the segment with your jacks and the segment with your refinery. So far, this idea is simple enough that the values could be tweaked to have zero impact to early gameplay, like with coal power, and only get introduced gradually as your base grows. The next step is when you want to scale up using trains. A fluid wagon intake/outake is at the top, and so have zero pressure. You need a pump get stuff in or out. Height matters. You look back at your base and notice that your tanks aren't filling up all the way, because you don't push enough pressure to raise the fluid from the ground. You start to add pumps to fill them up, and then notice that it breaks a recipe that you used to crack light oil into petroleum. The buffer tanks have so much pressure in them, that the Chemical Plant's safety triggers and shuts down production. You add a tank to fix it temporarely, fluid redistributes, pressure drops, cracking resume, and you start thinking about how to limit volume in the tank with automation to prevent the presure from getting too high. You just learned how to throttle the presure of a pump using a tank.

What I really like about this idea is how elegantly it fits into the current game progression. It adds just enough difference to keep fluids fun and unique. It also adds new kinds of designs that made little sense today, and becomes useless with your new version, such as presurised pipelines. You could, if you wanted, trade the train route for a 10k+ tiles pipeline, but without pressure, it would take an eternity for your machines to start consuming the fluids on the other end, and even then, fluids would only move around slowly. You can't just ignore the problem and wait for the pipe to fill because Pumpjacks don't have enough pressure to ever get the machines to work on their own. Just adding a single pump won't cut it because the segment is so long it won't raise pressure enough. You'd need a compression station, with many pumps to try to produce enormous pressures. But then, you have the opposite problem at the other end. Even if the volume moves instantly from one end of the pipe to the other, you have to decompress the fluid to make the hack worth while. We already learned how you need tanks and automation to buffer the pressure, so this is now a challenge instead of an easy way out.

There's also a whole world of mods out there to throw a wrench in the problem. Pipes with different volumes/pressure ratings. Recipe pressure tweaks. Recipes for the same item with different presures. Variable pressure pumps. Actual water towers to store more pressures. Underground pipe could have higher pressure than overground pipes...

All of that just by introducing a single multiplier used to control the speed at which volume moves from one segment to another, and some requirements to satsifies on inlet and outlets. I don't know how hard it would be to implement, but from a gameplay perspective, it feels like an easy to learn / difficult to master mechanic that would add a lot to the game.

[motmontheinternet]

It doesn't look like future FFFs are going to actually give any information that fixes the problem this one has introduced. You've just released an announcement that you've removed a gameplay mechanic and "stay tuned for future updates!"

If you actually have other meaningful changes to fluids to talk about, you should have talked about them with this update.

[GrandMasterB]

actually deals with engineering tasks.

The most complex engineering task, "produce more than you consume, slap on a pump every two pipes"?

All those "hardcore" players, hardcorly placing pumps, surreal

I like to use pumps. But I also like not have to use too many.

In 1.1 the behavior was funny and sometimes contradicted logic, but it tried to simplify reality. The new system does not seem to simplify reality. It changes real behavior into something magical. If we want to, we can play any other game where the goods are magically teleported into an imaginary pool and are then available everywhere.

One of the main fun factors in Factorio is transporting things to where they are needed. Simplifying pumps and piping, means removing the fun.

[BrainlessTeddy]

Sometimes it is easier to ask for forgiveness than to ask for permission...

Weird deja vu. I just heard the line yesterday when I watched an episode of The Legend Of Korra.

[BEEFE]

For what it's worth, as much as I'm annoyed by losing interesting pipe behavior, that's far more than offset by finally dealing with all the jank that shows up in any non-trivial plumbing setup. Even if this update is all we ever get on fluids (which we've been told it isn't) this is still a big improvement over the status quo, just not as big an improvement as I'd wish for.

That train unloading example in the FFF is too real, and a much bigger problem than fluids traveling faster than they seem like they ought to.

[GrandMasterB]

As an engineer and simulation specialist for thermal systems, I am sad about this change. From my point of view, the fluid system, as bad as it may be, was/is the only part of the game that actually deals with engineering tasks. The rest of the game only creates logistical problems. Even if only very few people actually implement just-in-time mechanisms or other real logistical solutions. Most of the people only buffer huge amounts of resources and intermediate products, the opposite of the just-in-time concept. Proportional-integral-controllers are also a rarity used concept. Only produce needed intermediate products is also rarity used concepts.

It makes me all the more sad that this one game mechanic is not being improved or fixed, but simply simplified. I would like to help you to realize a simplified but realistic implementation of the fluid systems.To do this, you can merge longer segments to increase performance. The dynamic pressure can be neglected here. Static pressure, however, offers a simple way of representing reality without becoming too complex. Pumps can also be greatly simplified. But it requires a static pressure at each element input and output. At each tick, the elements could calculate the mass flow independently of other elements. While pumps would only represent a fixed pressure difference.So independent of the pressure level or the pressure difference between input and output.

After the quality feature, which adds non-physically explainable effects to products in an imaginary way, because of the not clearly defined quality, this would be the second step backwards in the direction of the causal game.

I kinda like this approach. In this, would pressure remain constant along merged segments of pipe, or a fixed pressure drop based on the segment length? Would junctions create new segments? (If you had a pipe T, what would happen to the pressures in the two branching pipe runs in your idea?)

Otherwise, if I'm following:

- pumps provide fixed pressure differences to ensure consistent flow;
- output fluids are at set pressures (output source dependent) and stop if the pressure exceeds a threshold to prevent over-pressurization ("Output Full");
- inputs need to observe a minimum pressure to consume the fluid ("Needs Resources"); and
- this would lend different fluids to have different static pressures based on fluid properties (viscosity or density) if they wanted to go that far.

Hello doktorstick,
I had formulated a comprehensive answer and unfortunately it disappeared nowhere. So, sorry if my answer is a little shorter the second time I write it.
The basic idea is to calculate the mass flow with a time delay. I don't know if the Factorio engine allows this, but it would simplify and decouple a lot. Normally, linear and non-linear equation solvers are used in system simulation. The problem is that large systems increase the size of the equation system and thus increase the calculation time. For a game like Factorio, it is not useful to solve the entire equation system with a classic equation solver.

First, your questions:

1) Fixed pressure drop based on the segment length?
no, the pressure loss depends on the mass flow and the length.

2) Would junctions create new segments?
Yes.

3) If you had a pipe T, what would happen to the pressures in the two branching pipe runs in your idea?
There was ambient pressure on all construction machines and tanks. The pressure would therefore continue to increase along the length of the pipe. If the pipe reaches a T-piece, the two pipe pieces calculate a pressure that should exist in the T-piece. But they don't have to be the same. The idea now is to use the pressure difference to calculate the mass flow distribution. The lowest pressure is that which the inlet uses to calculate the mass flow. If the pipe sections were the same and the filling level in the pipes was the same, the mass flow would be evenly distributed.

4) pumps provide fixed pressure differences to ensure consistent flow
yes, but they can also be easily regulated. Higher speed, higher pressure difference. There are lower pressures at the pump inlet and at the outlet higher.

5) output fluids are at set pressures (output source dependent) and stop if the pressure exceeds a threshold to prevent over-pressurization ("Output Full")
When the tank is full, the mass flow in the element is set to 0

6+7) inputs need to observe a minimum pressure to consume the fluid ("Needs Resources"); and this would lend different fluids to have different static pressures based on fluid properties (viscosity or density) if they wanted to go that far.
Yes, fluid based pressure differences would be possible!

I think I'll set up a Modelica library and try it out in OpenModelica. I hope this answers your questions.

Kind Regards, Bobo

[farcast]

Hmmmm.... I think I'll like this change.

For low demand fluids (lubricant for example), I think builds using the two systems would end up nearly identical. The difference is only noticeable for high demand fluids. When throughput isn't enough in the old system, you have to split the build into smaller pieces, cram those pieces closer together, and/or replace more and more pipes with pumps until it works. In the new system, a low demand build will work just as well when used as a high demand build.

It's unfortunate that there's one less problem to solve, but I do agree that pipe throughput was a particularly frustrating problem to deal with. We still have pumps and circuits, so there's plenty of room for complex fluid management, and the irrational need (not-so-irrational for space platforms) to build as compact as possible will still ensure pipe routing is a non-trivial problem.

[Skellitor301]

Honestly I welcome this change. Yes it's not realistic /in/ the pipes but the old system also was not realistic in how the pipes were meant to be used. Pipes are meant to bring fluids from A to B and split between directions because fluid dynamics. The old fluid system did this poorly, very poorly. It's not realistic to force pipes to flow properly so all the machines that need it can get fluids. I find it funny that people who complain about how the pipes are no longer realistic mainly because pipe flow is different, and most completely miss the functional realism that the old system completely lacked. Rseeding did a good job showing these issues, it's not realistic to have pipes full of fluid, and only have the first few machines in a line only get supplied. That's not how pipes actually work, machines dont just suck the flow out of the machines, the flow spills into these destinations XD

tbh, this fix is more realistic than the old system for this reason. I'd rather have pipes that actually work more true to life with how they supply bases than have the minor bit of dopamine watching fluid flow chaotically through a pipe, only for the disappointment of the destination being starved in some areas and flooded in others.

[Panzerknacker]

Honestly I welcome this change. Yes it's not realistic /in/ the pipes but the old system also was not realistic in how the pipes were meant to be used. Pipes are meant to bring fluids from A to B and split between directions because fluid dynamics. The old fluid system did this poorly, very poorly. It's not realistic to force pipes to flow properly so all the machines that need it can get fluids. I find it funny that people who complain about how the pipes are no longer realistic mainly because pipe flow is different, and most completely miss the functional realism that the old system completely lacked. Rseeding did a good job showing these issues, it's not realistic to have pipes full of fluid, and only have the first few machines in a line only get supplied. That's not how pipes actually work, machines dont just suck the flow out of the machines, the flow spills into these destinations XD

tbh, this fix is more realistic than the old system for this reason. I'd rather have pipes that actually work more true to life with how they supply bases than have the minor bit of dopamine watching fluid flow chaotically through a pipe, only for the disappointment of the destination being starved in some areas and flooded in others.

I think it actually DOES work like that IRL. If you have a pipe and hook a few machines up to it inline, if a machine takes a lot of fluid from the pipe it causes a major pressure drop, if the pressure drop is large enough then a machine further up will get starved for sure.

[Faerwald]

Honestly I welcome this change. Yes it's not realistic /in/ the pipes but the old system also was not realistic in how the pipes were meant to be used. Pipes are meant to bring fluids from A to B and split between directions because fluid dynamics. The old fluid system did this poorly, very poorly. It's not realistic to force pipes to flow properly so all the machines that need it can get fluids. I find it funny that people who complain about how the pipes are no longer realistic mainly because pipe flow is different, and most completely miss the functional realism that the old system completely lacked. Rseeding did a good job showing these issues, it's not realistic to have pipes full of fluid, and only have the first few machines in a line only get supplied. That's not how pipes actually work, machines dont just suck the flow out of the machines, the flow spills into these destinations XD

tbh, this fix is more realistic than the old system for this reason. I'd rather have pipes that actually work more true to life with how they supply bases than have the minor bit of dopamine watching fluid flow chaotically through a pipe, only for the disappointment of the destination being starved in some areas and flooded in others.

I think it actually DOES work like that IRL. If you have a pipe and hook a few machines up to it inline, if a machine takes a lot of fluid from the pipe it causes a major pressure drop, if the pressure drop is large enough then a machine further up will get starved for sure.

Yes it does work like that in real life. And in real life we also usually have competent people designing these systems. What would happen with larger lengths of pipe is that the pump would be sized up appropriately to mitigate the friction losses. Factorio should make pump connected to larger segments draw proportionally more power to add balance back.

I like the new changes but the increased power draw to feed larger segments would make sense.

[justAstoro]

So fluid wagons and pumps are pointless. Next step is to make chest share one infinite storage to get rid of a trains. After all it's a very confusing mechanics for new players, a big nono for a casual game like factorio.

[Lunardiver]

Please don't actually implement this in 2.0. This completely removes any challenge the current system gives you to get fluids from A to B. If you're going with this solution, at least don't make it THIS simple. That's what Factorio is all about: overcoming challenges. Where's the challenge in these proposed changes?

[vinkami]

I've played Thermal Expansion for quite a few times, and I have never felt annoyed or anything with its fluid system, so my initial thought is that it will also be quite fine for Factorio.
But then I realized you don't usually make long trips with fluiducts in modded Minecraft but there're so many situations you just want to make an extremely long pipe in Factorio so the new system might be increasingly more unrealistic depending on pipe length.
Overall I still liked the TE solution so I'd be good seeing that as a change, or even, adding that as a setting when generating a map to see how they differ.

Btw how does Mindustry's liquid system work? Just curious if it's good in anyway for Factorio.

[Merlin]

Probably someone is relying on this core feature :>


And for real, I would love to learn more about this new solution from an implementation standpoint.

[Sopenas]

After thinking for a while i am not sure about this change. what is the point of transporting fuel now with trains when you can instead just build one single pipeline and connect oll sources and demand to it. this pipeline can be as long as I need, it can cover my full megabase

maybe each system still could be limited somehow. Maybe introduce something like diminishing storage returns or diminishing fluid speed in system as it grows bigger and bigger. so that people would still be interested in building smaller separate fluid systems to get full benefit

[functional]

For what it's worth, as much as I'm annoyed by losing interesting pipe behavior, that's far more than offset by finally dealing with all the jank that shows up in any non-trivial plumbing setup. Even if this update is all we ever get on fluids (which we've been told it isn't) this is still a big improvement over the status quo, just not as big an improvement as I'd wish for.

That train unloading example in the FFF is too real, and a much bigger problem than fluids traveling faster than they seem like they ought to.

Precisely this. The problem with status quo is that it becomes incredibly annoying when you start to deal with real throughput where it has to be pump - pipe - pump or multiple parallel lines. Then even a single S-bend for example requires so, so much jank. And also the train example... yup, I've had so many issues in modded gameplay due to that problem. Has to do with needing large enough buffers which can hold content of a whole train and take into account the time it takes for train to come by with the product when needed.

[functional]

After thinking for a while i am not sure about this change. what is the point of transporting fuel now with trains when you can instead just build one single pipeline and connect oll sources and demand to it. this pipeline can be as long as I need, it can cover my full megabase

maybe each system still could be limited somehow. Maybe introduce something like diminishing storage returns or diminishing fluid speed in system as it grows bigger and bigger. so that people would still be interested in building smaller separate fluid systems to get full benefit

The point is very similar as it is with belts vs. trains. In normal gameplay belts could provide more than enough throughput realistically versus trains. When you scale, you want modular setup and trains do that. You absolutely do not want to put pipes into every possible direction and you also need to solve certain things like balancing production of fluid too which requires pumps and tanks with circuits.

Whenever someone asks "whats the point with trains", it makes me instantly think that they do not use trains that much to begin with...

[RoastCabose]

The way I see it is as a trade off.

Old System
Pros:

• Interesting behavior at lower scales

• Throughput feels more grounded

• There's more of a puzzle challenge with the current system

Cons:

• Nonperformative

• Leads to a lot of awkward building considerations like needing to use absurd amounts of pumps and always using undergrounds when possible

• Completely misses pressure as a thing to be modeled

• Does not scale to handle large volumes of liquids.

• Major failed edge cases like:
  1. Placement order matters
  • Super nonintuitive fluid splitting

New System
Pros:

• Works in an immediately understandable way

• At high throughputs it's realistic enough

• Doesn't have tons of breaking edge cases

• Scales up simply to large amounts of volumes

• Problems at low volumes are easy to understand

• Very performant

Cons:

• Also completely ignores pressure

• At low volumes it acts in a bizarre way (though on purpose)

• Unlimited throughput, even with the limitations of input, output, and pulling rates, feels bad as a design choice

I definitely see the tradeoff as worth it. The new system is definitely way more intuitive and performative, it's scalable and it doesn't fail in as many situations. It is however definitely way simpler. For me, complexity is a cost. For other people, complexity is a feature. I'd rather have something simpler and easier to work with that still retains depth then to go for marginal gains in design space that has high costs.

All that said, I hope there are ways to increase the depth of this new system without majorly increasing either complexity or performance.