Friday Facts #416 - Fluids 2.0

[Panzerknacker]

Also, another quote from the FFF:

"However, during our playtesting of Space Age, it became clear that the existing system would no longer do the job. The production scaling afforded by the new machines and quality brought the flow algorithm to its knees."

What I can answer then, why don't you keep your "new machines" then. I assume you are referring to things like the foundry. In essence these "new machines" are nothing more than a assembling machine with a new graphic and different values for the crafting speed, stuff that might as well be modded in. I don't want more of that boring binary stuff if it means giving up one of the actual simulation mechanics in the game.

Or, putting it even better, the fluid system was actually the only reason those "new machines" could be interesting at all, due to the challenge of feeding them with enough fluids. That all becomes trivial now.


What about adding a "hard mode" to the game that will preserve the old fluid system? I also hope you will keep the Marathon difficulty in the expansion, maybe it could be part of that.

[Svip]

If your output matches your input, and other factors aren't forcing a break in the segment, then you don't need storage tanks. Storage tanks appear only to be useful when produced is more than consumed, because as - mentioned above - adding a storage tank means you lower the rate a pipe segment is filled up, since a storage tank now count as a pipe piece just with a much higher capacity. So adding storage tanks will actually lower your throughput.

Actually adding storage, doesn't lower your throughput, it just adds volume to the segment, since pipes and tanks are treated the same.

Quite, but since it now takes longer to fill the pipe segment, and thus draw from the segment (assuming nothing but adding the tanks changes), your throughput (to the consumers) has been reduced. Of course, if your producers outperforms your consumers, they will eventually balance it out (but it could potentially take a long time).

In fact the example in the FFF shows 8 plants, I would like to know what would stop 80 or even 800 plants on that same pipe? (Other than not having enough producers.)

Based on what is told in the FFF, nothing.

Would the pipe fill up to 100% first before filling the storage tank above 100 fluid units? Or is the entire pipe->tank->pipe network treated as a singular 'chest box' for fluid?

From the FFF, it's clear that each piece of a pipe segment (pipes and tanks) are filled a percentage, so for the pipe to be filled 80%, the tanks must also be filled 80%.

Let me put it another way.

Fill up the 'pipe segments' first before filling up the 'storage tank segment' would let the machines pull the full 'pipe segment' content without waiting forever for the 'storage tank segment' to fill up to pull a certain amount of "XX units per second."

IE: Oil Field pump jacks push oil to 'A pipe segment' that connects to 'B Storage Tank Segment,' which is connected to 'C pipe segment' and 'D pipe segment.'

Are A, B, C, and D treated as one singular fluid box, or can A be 100% full and be distributed 50%/50% into C and D with any unused leftovers above what pipe segments can hold backfilling in B tank?

Given there are no machines nor pumps separating A, B, C and D, they are the same pipe segment, and each piece will fill at the same percentage rate (not in absolute units).

[sanderburuma2]

I'd think that it would still possible to see liquid flow in the pipes just by calculating the general direction of liquids in a segment based on inputs and outputs. If if input is far greater than output, the flow is from the inputs into the rest and vica versa. If they're similar the flow is from the inputs to the outputs.

Flow could be gradually reduced in some manner once a segment exceeds a certain maximum distance

[MeduSalem]

What about adding a "hard mode" to the game that will preserve the old fluid system?

Similar things as a "hard mode" have been suggested when other "controversial" changes were made in the past; but in practice only a minor subset of hardcore players would ever play that way and it is not worth dragging around all that legacy systems. For any future changes you make to the game you would always have to keep the legacy stuff in mind as well, possibly having to do double the work. In the end it would just be an additional (code) maintenance nightmare.

So from a pure developer's point of view I would not even want to start keeping around legacy systems and wasting additional time with them. It only opens a can of worms that will be hard to close later.

[o6dukeleto]

Quite, but since it now takes longer to fill the pipe segment, and thus draw from the segment (assuming nothing but adding the tanks changes), your throughput (to the consumers) has been reduced. Of course, if your producers outperforms your consumers, they will eventually balance it out (but it could potentially take a long time).

Production into a pipe segment is unlimited.
Consumption from a pipe segment is proportional to how full it is.
Throughput in a segment is instantaneous.

Hence, production will outstrip consumption until the segment gets full enough and it equalizes. (unless overall production is less than overall consumption -- but then you never be able to support all your consumers.)

The whole consumption pulling proportional from a segment doesn't really mean much -- since production pushing into a segment is unrestricted and transport is instant. (I think consumption being restricted really only provides a "fake flow" of liquid.) Basically, if how full the segment is is restricting consumption, it will eventually fill up enough to NOT restrict consumption, unless the segment has too small a volume - and this can be fixed easily.

As for the segment volume being to big, and equalization time too long, this would have to offset the storage needed for trains and the time it takes for trains to transport liquids. Since underground pipes only have 200 units of storage, you likely can go a long way across the map compared to the storage needed for transporting liquid by train which is not instantaneous.

Hopefully, they bring in restrictions to make it so that we need to use multiple segments and keep trains transporting liquids viable. I do like the idea of segments, I just don't want the optimal solution to be a single segment per fluid.

[XT-248]

Let me put it another way.

Fill up the 'pipe segments' first before filling up the 'storage tank segment' would let the machines pull the full 'pipe segment' content without waiting forever for the 'storage tank segment' to fill up to pull a certain amount of "XX units per second."

IE: Oil Field pump jacks push oil to 'A pipe segment' that connects to 'B Storage Tank Segment,' which is connected to 'C pipe segment' and 'D pipe segment.'

Are A, B, C, and D treated as one singular fluid box, or can A be 100% full and be distributed 50%/50% into C and D with any unused leftovers above what pipe segments can hold backfilling in B tank?

Given there are no machines nor pumps separating A, B, C and D, they are the same pipe segment, and each piece will fill at the same percentage rate (not in absolute units).

Then you know my answer. It might not live up to my expectations.

[Kostriktor]

Here it is! (beep boop)

https://factorio.com/blog/post/fff-416

i read lots of "i did" but who is writing ?

[Koub]

Here it is! (beep boop)

https://factorio.com/blog/post/fff-416

i read lots of "i did" but who is writing ?

It's written at the top of the FFF

[imi___]

Honestly, I am not so keen about this change.

"Fun beats realism".. sure, I know that. Its just that factorio is a game about spatial automation problems and you just removed ANY incentive to do anything spatial with pipes.

If I read the changes correctly, the new meta is now to never ever use fluid trains again - they no longer make any sense. Piping everything through the whole island is much more efficient (in terms of throughput, complexity and most likely UPS).

Moreover, having everything in one single huge segment is probably the fastest thing to go (similar to "having everything in one big electrical network").

I hope you reconsider these changes...

[TioQueToca74]

This looks really nice, but I do miss the directional flows in the pipes. This was always such a nice moment when you turn on a chemical/fluid plant and you see all the water and oil rushing in.

Any chance that might be added again?

I don't think that makes sense at all, the segment itself has not fluids flowing to a direction, they all act as a whole, I don't even think it's possible, every pipe has the same fluid amount, so there's no realistic flow simulation, in a long pipeline, top left pipe will have exactly the same amount than bottom right pipe.

I think is a good tradeoff to lost that animation, to have a more predictable pipeline, I will miss the realistic one, but tbh, imho, the junctions were very crazy in the old algorithm XD

[aka13]

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

[TioQueToca74]

That's the first FFF about the new Factorio that I have just read and thought... hold on... so... you just did that? And this wasn't a build up to a series of trial and errors that eventually came out with something that worked similarly to the old system and was still workable?

It's disappointing to be honest. I can pump oil from 10,000 miles away and it will instantly appear at the other end? It's more a teleporter than a pipe.

I'd far prefer the old system, by a LONG way. The quirks are what makes it, not a watered-down perfect, zero-maintenance solution. It's just ripe for exploits that destroy the immersion in the game.

I realise that it's hard work, but the old system needs to be kept if this is the alternative. It adds nothing and takes away a huge aspect of the game, and makes fluids become "just connect this wire and it all works" which removes huge tracts of the fun. Completely destroys barrelling as well - what's the point when you can instantaneously transport all fluids everywhere? I can even see someone make a single long pipeline to a remote station and "schedule" the pipes with circuits to transfer every fluid product into a storage tank, switching using circuits as to what the current fluid is to pump, and what tank it's put into at the end. One pipe, eliminates the entire fluid, barrelling and train transport of fluids in one hit.

I don't "pipe up" (sorry!) often, but no... let's go back to the old way.

I'm agree, would be nice to make that an optional change, maybe an ingame startup option like "realistic fluid flow", which can by default by off for 2.0 game. This game is all about complexity, the more complex the game is, the more fun it becomes, I would only want the old system "build order junction logic" to be fixed, if possible (probably not?)

It's realistic that pipeline length decreases throughput, that's how it works in reality because the longer the pipe the more resistance it imposes. You simply need more paralel pipelines if you require high throughput over a long distance. Or you must produce solid products locally near a oil source and transport them by train.

Being able to teleport a basically infinite amount of liquid over any distance (as long as supply > demand) is utter nonsense.

Isnt it possible to keep the old system and just change that at an intersection, fluid spreads to both directions depending on the fill percentage?

only when the tube is completely filled is it a 100% teleportation. You can extract a percentage of the filling per second.
Let's say a machine can suck in 5l/sec. But the pipe is only 20% full because it is very long. Then your machine only gets 1l/sec.
But the ratio could also be different, the less filled the less she could suck in. So instead of 1/5 at 20% only 1/10 at 20% filling or even more extreme.

What I am saying, is "as long as supply > demand". In that case, the pipeline is eventually going to fill up to 100% which will eventually ALWAYS enable the teleporting/infinite flowrate.

I already think belts are overpowered in this game compared to trains because they allow totally free transportation (no fuel cost like trains). Now you can totally ditch the trains, when it comes to fluids.

You say trains are OP compared to belts, but if you run a belt over 1000 tiles, that'll cost you 3000 plates + 15000 of the resources your putting on the belt if it's a full belt for a grand total of 18000 iron ores taken by your system if you're running a belt for that
Compare that to a train, that'll be around 3500 resources to make your system only assuming you didn't reuse any rail and about 2000 resources in transit

Likewise, if you use pipes to make some sulfuric acid over such distances, you'll have to invest 100000 units of sulfuric acid to fill the pipe, which is about 30 minutes of a factory working to make your pipe work, 2000 plates, and 10000 sulfur, which is a huge waste

So the only way I could see reasonable to use hyper long pipes is to move water, but water is available everywhere

That's a really good argument against the use of ultra long pipes in the new mechanics, I like your argument, and will buy it

[raven2k3]

I know most of us are using mods for that but it would be really nice if you can also focus a little bit on the endgame / megabase, because in the end you want multiple big storages of liquids and hundredts of liquid storages have an noticable impact on the UPS.

It would be nice if you can add these things to vanilla:
- big fluid storages (idk 4 x bigger with 12 x more capacity)
- big pipes with extra long range and troughput which are connectable to the normal pipes
- a visualization of the fluids on map level would be also a nice quality of life feature

Something like Fluid Must Flow "FluidMustFlow" + "PipeVisualizer" in vanilla because this will improve the overall performance in the end game and you don't have to lay millions of pipes to the next base.

Personally I also prefer more realism tbh, so not sure if this is a nice update.
Anyway - Thanks for the hard work nice updates!

[FasterJump]

A rewrite was needed, but this seems rather disappointing.

Teleporting fluids over unlimited distance looks like giving up to the pipe throughput problem.

This to nullifies the throughput challenge. It would also nullify the challenge of building a nuclear reactor setup.

As others have noted, you just need to connect all the machines in your base to 1 pipe and it will just work.

The fluid wagon also loose its throughput advantage

Why not removing pipes entirely?

The change described in this FFF would work as a quickfix but I'm sure that better can be done in 2.1.

A few ideas:

How about limiting fluids segments to segments of up to 8 or 10 tiles?

How about making fluids quantities an integer number rather than a real number? A machine would typically consume 1 unit of fluid, and fluids would not split in quantities lower than 1.

Junctions could be programmed with soft priorities (i.e. if 3 empty pipes are competing for a fluid unit at a junction, one of the direction would receive priority.

Alternatively, terrain would have an elevation value, and the elevation value would determine which pipe gets supplied first. This would make the system deterministic.

[Super Mikal]

This is an improvement, but I still wouldn't consider it "good", as I think it takes too much of the challenge away. The biggest example of this, which has also already been mentioned by others, is water supply to nuclear plants, which sounds like it'll be almost trivial to solve now. I hope you'll keep iterating on this until and even after 2.0 ships.

You can also cram unlimited amounts of fluid down a single string of pipes. So while your nuclear power still needs a bunch of off shore pumps it only needs one pipe connecting them to the reactor.

[Svip]

How about making fluids quantities an integer number rather than a real number? A machine would typically consume 1 unit of fluid, and fluids would not split in quantities lower than 1.

I am not sure what the purpose of this suggestion is, but fluids are already in integers. A storage tank can hold 25000 units of fluid precisely to avoid using floating numbers.

Junctions could be programmed with soft priorities (i.e. if 3 empty pipes are competing for a fluid unit at a junction, one of the direction would receive priority.

The old system already has a "soft priority", it's based on which pipe was built first.

[GregoriusT]

How about making fluids quantities an integer number rather than a real number? A machine would typically consume 1 unit of fluid, and fluids would not split in quantities lower than 1.

I am not sure what the purpose of this suggestion is, but fluids are already in integers. A storage tank can hold 25000 units of fluid precisely to avoid using floating numbers.

Uhhh there is frequently a decimal separator in my Pipes so I am not sure if you understand what that means, even if it was fixed point integer with 250000 units, it still has issues.

[Sphinx]

Why should they make another fluid FFF when this would be all? I suspekt there will be some more things than we know for now.

an interesting point that is often mentioned here is nuclear reactors. Apart from very small ones, I've never built a big one because the pipe stuff was too annoying for me. So I got a blueprint from the net and that was it.
And by annoying I don't mean that it was too complex, apart from thinking its a bug when liquid behaves stupidly, I never interacted much with the liquid system. When it stopped working, I never looked for a solution. I just built a second production system to get more output.

And I rarely used the most efficient way, but mostly the one that was fun for me. I love building a train system, so I would never replace them with raw ones. But I've been annoyed by the low UPS a few times and never built a proper magabase for that reason. So if this helps significantly with the UPS, I'm all for it.

[Tertius]

There is no mention about "teleport" and "infinite throughput" in the FFF, because the new pipes simply don't work out like this.

Even if there is no limit with input, there is limit with output. So there's no infinite throughput. There are no machines able to achieve infinite throughput. Very high output drains the pipe, which lowers the fullness, which lowers the throughput, until equilibrium is achieved.

Even if input fluid appears instantly at the other side of the pipe, you cannot extract it, because output is limited by fullness. You're able to extract some of it too early in comparison to some flowing fluid, but that's a matter of just a few ticks. You will not really see this if you watch the running game.
And if you're able to extract in a very high rate, because the pipe is nearly full, the behavior isn't different to the real world. You're inserting fluid at one end, and extracting some different fluid that has already flown to the other end. It appears as teleport even in the real world, but actually the fluid will flow.

What is actually not included in the Factorio simulation is the pipe diameter. In the real world, pipes are made with bigger diameter the higher the requested throughput and length. There is the Hagen-Poiseuille equation that tells throughput increases proportionally with r^4 and decreases proportionally by l (so it's a factor of 1/l). Among other factors, which are constant in the Factorio simulation, both 1.1 and 2.0.

So if you want to double the throughput at double the distance in the real world, you have to increase the radius of the pipe by sqrt(2). That's not a very big change, and that's what is actually abstracted away with the standard pipes in Factorio. In 1.1, you build another pipe for higher throughput. In 2.0, imagine you're building a pipe with a slightly bigger diameter. Since actually implementing different pipe diameters is not an interesting addition to the game, I'm fine with ignoring that detail.

[MeduSalem]

A few ideas:

How about limiting fluids segments to segments of up to 8 or 10 tiles?

Junctions could be programmed with soft priorities (i.e. if 3 empty pipes are competing for a fluid unit at a junction, one of the direction would receive priority.

Alternatively, terrain would have an elevation value, and the elevation value would determine which pipe gets supplied first. This would make the system deterministic.

All of them are terrible though. ^^


If there are "random" segments of just 8-10 tiles it would behaving weird & unpredictable again. The algorithm would automatically have to split longer pipe sections according to such an arbitrary rule, but they are not necessarily apparent to the player. And even if you would know it as a player, it will probably be annoying to control where the algorithm would make the "splits". Most people would not get why the hell it is like that and then place ungodly amounts of pumps again in an attempt to get a control over where the pipe segments are.

Junctions with a priority set by the algorithm would also be weird. Because most people expect them to split evenly. If one direction gets priority over the other it would also behave annoying & possibly unpredictable. Especially if there is no way to influence which one gets the priority.

Considering a terrain elevation value for the fluid simulation is probably the worst of them all because of how the game's projection is "flat" and does not give much of a feeling that there even is an elevation change. You never have the feeling that you are laying a pipe down a hill or up a mountain. There is no indication for that and I think with the specific projection the game is using it would be really difficult to implement something where you would get a good feeling for elevation. Elevation changes would work better if the game had a 3d perspective or axonometry where you can see the elevation change.