Friday Facts #430 - Drowning in Fluids

[Loewchen]

I am also in favour of a more gradual decrease in pipe throughput. A gradual decrease provides an optimization puzzle where a pipe network may not have maximum throughput but still more than is needed, that is for the player to find out in each case.
A cut-off like now on the other hand only adds a necessity to add pumps sometimes without any options or choices.

One issue I can see with this is, that you cannot use an alert as method to inform the player when it can be deliberate to exceed the segment size. But I am sure the new overlay could convey with a symbol that there is a segment border with limited throughput and the gameplay advantage over freezing the complete segment is significant imo.

[meganothing]

I am also in favour of a more gradual decrease in pipe throughput. A gradual decrease provides an optimization puzzle where a pipe network may not have maximum throughput but still more than is needed, that is for the player to find out in each case.
A cut-off like now on the other hand only adds a necessity to add pumps sometimes without any options or choices.

One issue I can see with this is, that you cannot use an alert as method to inform the player when it can be deliberate to exceed the segment size. But I am sure the new overlay could convey with a symbol that there is a segment border with limited throughput and the gameplay advantage over freezing the complete segment is significant imo.

Since any pipe network is having the same limit everywhere, the current throughput decrease could easily be shown in the tooltip when hovering over any of the pipes.

Exceeding the limit and having less than 100% throughput should be the normal case, just like in 1.1.

[LddStyx]

Feedback to the FFF: There isn't much play in a system that just tells you where to place the pump, some kind of a gradual penalty would leave more room to debug the systems yourself and solving the problems yourself.

-------------------

+1 for a pressure system.
I wrote up a similar idea with a much worse explanation a few days before, but the post seems to have disappeared instead of submitting.
Probably due to a link to my inspiration. (a AlphaPhoenix video on YouTube where he explores how electric currents work in a maze with a water based model)

Anyway I'd like to add the few idea that I had that could go along with this kind of pressure system:

*Pumps effectiveness depends of saturation and pressure
This keeps system capacity based delay intact from the previous fluids update and would stop the players from shortcutting their fluid systems by keeping the long distance at low pressure and just adding pumps before every machine. It leads to a more intuitive high pressure long distance liquid transport where you'd need to add pumps every so often, but there are benefits and drawbacks between different distances.
Less pumps = more time to reach full saturation after loss of pressure/saturation drop
More pumps = faster recovery from pressure drops, but more expensive to build

*The ability to gate machine from working (or working at reduced effectiveness) at different saturation or pressure levels.
This let's the devs order the way that different processes shut down once pressure and saturation drops in a liquid system to cause interesting problems. It could also be used to lead the player towards low UPS solutions where the system is at a constant 100% saturation.

*Bonus idea (with lots of potential problems) Some machines that prefer a low pressure input.
This could create BioPunk-flavored "organic" systems where some machines work optimally at low pressure and others at higher pressure with a regular heart beat enabling/optimizing different processes. You could do things like create a "Heart" like setup (Pump -> Tank -> Pump with some logic) where you can fill a tank to capacity at reduced speed (due to low saturation) and then back out again into the same system at a higher speed and pressure.

[Avezo]

Not sure I like the change, in real life pipelines easily go for thousands of miles.

[GregoriusT]

Not sure I like the change, in real life pipelines easily go for thousands of miles.

real life pipelines also only have one inlet and one outlet that actually drains the fluid, so you dont need to worry about things like a hundred people at once trying to fill their bathtubs with water or something, because real life pressure in pipes would drop harshly in that case so the pump on the supplying end would need to work harder and have a lot of latency in such a case, which COULD end up in a pipe exploding in the worst case. That is why multiple Pumps in a Line do make sense inside the Factory, since they can control pressure with much less latency.

[Raintingling]

The pipeline system could be like electricity system: pipelines don't store any fluid, they just connect equipment. And the speed of fluid can be limited by the length of the pipeline, or the mounts of equipment which connect to same pipeline system.

[vulduv]

I overall prefer this fluid 2.0 system over the computationally heavy 1.1 system. The pumps being slower, the water actually expanding into steam, the consistent behavior of pipes, that's all great! (Not sure why the fluid wagons had their capacity doubled though. But that's not a bad thing.)
But I have to agree with most here that having it just be a harsh cutoff point where the fluid just stops flowing does not feel like it would be particularly interesting or intuitive... (Same for it being a bounding box instead of something like total pipe volume.) Can't say for certain until we have it in our hands though. But I don't see how we could meaningfully engage with that 250 tile limit other than where exactly one puts the pump.
Not that every mechanic needs some mariana trench of depth for us to engage with, of course... And as the title of my reply says, I still prefer this over 1.1 fluids!

I have a lot of trust in Wube. And I'm sure they have more information on how such a system would play than any of us do. So I hope whatever they end up doing with all this (overly negative to be honest) feedback they've gotten, results in the best outcome for the game.
I'm also a bit worried about how this change would affect newer players, when the game suddenly tells them "That is too big!!" with no prior indication while building that they were approaching a limit.

Also while we are talking about the fluid system. Can someone please change the underground pipe length from a 9 tile gap, to a 10 tile gap? It says that it has an underground length of 10 in the tooltip, but that includes one of the inlets/outlets. So the actual gap between them is 1 less than that. Which is annoying when trying to have fluids cross a typical main bus design and end up being 1 tile too short, every time...

[Alvin M. J.]

Why use the main bus? I use train-bus and avoid mess.

[Koub]

Not sure why the fluid wagons had their capacity doubled though.

That specific part, I believe it's to keep fluid wagons and trains a better alternative than piping everything, at least in some use cases. If the pipes get "too good" when compared to trains with fluid wagons, who will use fluid wagons ? Having things somehow balanced will bring the engineers to make a choice between convenience and throughput.

[pepnou]

I've been reading fff since they starded writing them for the expansion. While i haven't understood every one of them, it was still interesting to read about their process: why did we do something / how did we do it. But this fff was the first that left me thinking "where are they going with that ???"
I'll just begin quoting since i see contradictions everywhere

... a pipeline would have been superior

Ok, the pipeline is too powerfull, it's the best choice. So what are they going to do to fix that ?

Pumps have been nerfed

Hum ... fix the train by nerfing the train ?

With three pumps per wagon that is 3600/s per fluid wagon, or about 14 seconds to fully pump out a wagon's contents. This is much more reasonable than the previous 0.7 seconds you could get in 1.1.

Great, i'm releaved to see that my train will unload slower than before and that i'm now forced to use 3 pumps per wagon. Awesome!
Also: fun time, you have a storage with a circuit controlled pump ? get ready to place 5 pumps for max throughput.

Pipelines are constrained to a 250x250 tile area

That's a 180 from before: semi-realistic fluid => infinite throughput but will stop working if you add that one pipe that will make it 251 long.

Speaking of infinite throughput:

... while there is no limitation on the total flow through a pipeline in a given tick, there is a hardcoded limit of 100 fluid per flow operation (6000/s).

... what ? here, i'll simplify:
"while there is no limitation, there is a limit"
Enjoy your infinite pipe throughput with limited input/output.

The output rate limit is particularly interesting because it makes the fluids feel much more like fluids again.

What's the point ? to me there is only two possibilities: you're starved on fluid or you overproduce the fluid.
"you're starved on fluid" : pipes will be empty => max throughput => doesnt matter
"you overproduce the fluid" : you'll fill the pipe up to the point the output throughput will be limited enough to balance with the next input demand => i'm not going to look at the level of my pipe at all time, why do i care if it's filling to 50%, 75% or 100% ? => doesnt matter

The special exception for storage tank flow has been removed.

which exception ?

I wasn't a fan of placing a pump every pipe to maximize throughput so i was interested by the fluid rework. Better fluid repartion amoung machines is great, the pipe visualizer is awesome, but in the end the pump (which went to a phase of complete uselessness) are worse than before, along side the train, and the pipe have ultimately less throughput

[Tertius]

Speaking of infinite throughput:

... while there is no limitation on the total flow through a pipeline in a given tick, there is a hardcoded limit of 100 fluid per flow operation (6000/s).

... what ? here, i'll simplify:
"while there is no limitation, there is a limit"
Enjoy your infinite pipe throughput with limited input/output.

The output rate limit is particularly interesting because it makes the fluids feel much more like fluids again.

What's the point ? to me there is only two possibilities: you're starved on fluid or you overproduce the fluid.
"you're starved on fluid" : pipes will be empty => max throughput => doesnt matter
"you overproduce the fluid" : you'll fill the pipe up to the point the output throughput will be limited enough to balance with the next input demand => i'm not going to look at the level of my pipe at all time, why do i care if it's filling to 50%, 75% or 100% ? => doesnt matter

You're not aware of the orders of magnitude at work, and how the several pieces of fluid mechanics come together to build the big picture.

By saying infinite throughput, it is just meant there is no mechanics to propagate one portion of fluid from where it enters a pipe to where it exits. Instead, it's instantly available to the whole segment, no matter where it's extracted. This isn't too strange, because in real life pipes, you perceive the same thing: You open your faucet and water comes out, and at the same time some fountain in the water works is drained for the same amount of water. The more people open the faucet the less pressure, so the less output, and this is exactly what is simulated by Factorio - it's just called fill state instead of pressure.

The limit of 6000/s of input and output is irrelevant for practical use, because there is no machine able to achieve this throughput. The value is the result of how fluids are implemented in the game engine. Each machine handling fluids has an internal buffer of 100 fluid for each fluid to input and the same for output. It's the buffers you see for example in an oil refinery. Each tick, these buffers are filled from the pipe segment (input) or emptied to the pipe segment (output). Since no machine is consuming 6000 fluid or creating 6000 fluid through their input/output buffers, this is no practical limit.

This leads to the orders of magnitude:
The 6000/s is an anchor for the percentage computation of the allowed throughput into or out of these buffers. If the pipe segment is just 10% full, you're only able to get 10% of 6000/s into the input buffer of your refinery. That's 600/s. Now look at your refinery, is it able to consume 600/s? No. It's consuming 100 oil every 5 seconds, that's 20/s. To get under 20/s, you need a pipe segment fullness below 20/6000 * 100 = 0.3%. Even accelerated with 10 beacons and 3 prod modules, it's 111/s, which is 1.85% fullness.
Is this really an issue for you? I guess, you consider a pipe segment that's 1.85% full as "almost empty, need more fluid". However, it's still inserting full oil input to all connected refineries.

The same is with out, just the other way round: emptiness instead of fullness: as far as I understand, it's 100% output (6000/s) if the pipe is 100% empty, 50% output (3000/s) if it's 50% empty, 1.6% output (100/s) if it's 1.6% empty or 98.3% full. A fully beaconed refinery outputs 80/s petroleum gas, so it's not constrained even if the pipe segment is already 98.3% full. I guess, similar to the above perception, you consider a segment 98.3% full as "almost full, have enough fluid", however all refineries are sill able to output at full speed.

These limits are only visible in the edge cases: they apply for the first and the last 0-2% of pipe segment fullness or emptiness. For normal operation, it's just full throughput for all connected machines.

About extracting fluid wagons in 14s instead of 0.7s:
This is a much more real number. Are you complaining the new fluid mechanics has some infinite throughput somewhere, and at the same time complaining a whole fluid wagon isn't being emptied under one second any more?

[LightningMaster]

Pumps have been nerfed to 1200/s (10x decrease), but this can be increased with quality.

I am wondering what happens if I put 10 pumps in parallel, connect their input to the same pip from chunk 1 and connect their output to the same pip on chunk 2. Will I get a 12000/s throughput then?

[Altoids0]

Hello! Zealous reader of FFFs, first time commenter. This fluid stuff is an exciting change! It's also big, but I won't complain until I actually get to play with it when 2.0 comes out.

I do have a question though about a particular alternative that... I'm sure was considered but I didn't find any comments about via the forum search :^)

It's clear that "One pipeline is one giant fluid volume" isn't really balanced (ergo the changes in this FFF), and having one-tile-big pipes for everything develops throughput problems (per #416). Is there any particular reason why a middle-ground, Fluids Must Flow sort of solution wasn't chosen? I'm sure it came up (Raiguard themself is the current maintainer of that mod), I'm just curious why it was not favoured over the current working solution.

Just some things off the top of my head in favour of having an alternate larger pipe for use in high-throughput scenarios:
- Ultimately, part of the puzzle of the game is altering your logistical lines as throughput demands increase. Kludgy yellow belts can become blue belts or trains or robot swarms or whatever. Pipes are the odd one out; there is only one, tiny "tier" of pipe and you use it in all contexts, from low-flow flame turret walls to these gigawatt legendary max-beacon monstrosities. Having another tier would allow more diversity and allow each context to be balanced separately. This means that the solution that fixes legendary petroleum does not need to worry about breaking flame walls.
- The pipe merging mechanic present in FMF could be expanded to maximize the flow of the 1.1 fluid system. In the mod it's only certain short straightaways that are merged, but you could imagine a merging system that goes deeper (maybe even merging volumes between entities internally). This would mean a pipe system that is maybe 2-32 tiles per volume (compared to 1.1's 1-11 tiles or 2.0's current 250x250 areas). In that case, a configuration like this would be possible (for example):

10-02-2024, 14-36-42.png (2.99 MiB) Viewed 1480 times

It is a lil' asymmetrical that for solids, greater flow out of a factory block has the cost of taking up more area with logistics, stuffing the space with roboports or a dozen lanes of bluebelts or a train's large rails plowing through the factory. Why would fluids only ever need slim 1x1 pipes to accomplish the same throughputs?

Hopefully this doesn't come off as rude or anything! ^_^ Much love to the Factorio team, super excited for 2.0 and the DLC!

[Loewchen]

Pumps have been nerfed to 1200/s (10x decrease), but this can be increased with quality.

I am wondering what happens if I put 10 pumps in parallel, connect their input to the same pip from chunk 1 and connect their output to the same pip on chunk 2. Will I get a 12000/s throughput then?

You will not get 1200/s per pump unless the source segment is full and the drain segment empty, but you will get 10x the actual transfer speed of a single pump with 10 pumps.

[LightningMaster]

Pumps have been nerfed to 1200/s (10x decrease), but this can be increased with quality.

I am wondering what happens if I put 10 pumps in parallel, connect their input to the same pip from chunk 1 and connect their output to the same pip on chunk 2. Will I get a 12000/s throughput then?

Its atually quite funny, imaging you use a long pip system to transport fluids. Then you need to build a pump station every 250 segment. in it, you put 10 or 20 pumps for each pip. And you need to use walls and gun-turret to protect that station form bugs. otherwise, you will find your oil supply was cut by bitters.

(What? you are saying I can use fluid-wagon to transport fluid? Na, I just want to use pips anyways )

[LightningMaster]

Pumps have been nerfed to 1200/s (10x decrease), but this can be increased with quality.

I am wondering what happens if I put 10 pumps in parallel, connect their input to the same pip from chunk 1 and connect their output to the same pip on chunk 2. Will I get a 12000/s throughput then?

You will not get 1200/s per pump unless the source segment is full and the drain segment empty, but you will get 10x the actual transfer speed of a single pump with 10 pumps.

Sure, just want to figure out the max throughput here. Thanks for clearify. So if one of my production plant consumes more than 1200/s fluid. then I can double the max throughput by adding another pump in parallel(persume that my fluid production is way more than 1200/s). Thats fantastic, because in 1.1, you can't do that, the pip segment at the joint will always full what ever you have 2 or 3 pumps, and the flow speed of the next segment depends only on previous one. Thus the flow speed remains the same.

[FasterJump]

If a gradual throughput penalty (and/or other tweaks) is introduced beyond 250 distance, I would suggest to change, in 2.0, the threshold to 128 or 64 instead of 250. As others said, 250 is huge.

1. Change maximum fluid unit size from 250 to 64
2. Release the extension (version 2.0)
3. ???: Tweak the system: take your time, and release a tweak in version 2.1 (such as a progressive throughput penalty rather than a full flow interruption)
4. Profit: Players see the change(s) as a buff in 2.1, and it's not breaking saves/bases.

[Panzerknacker]

I think a gradual throughput penalty is out of the question because it inevitably increases compute requirements by an unacceptable amount.

That is because the point of the new system is to treat the whole fluid network (or each of those 250x250 areas) as one big fluid box. That will dramatically decrease compute requirements. If you need to split up those big fluid boxes again to determine throughput for every pipe segment inside of them, you basically end up with the same problem as the 1.1 system when it comes to the amount of calculations required.

[Molay]

I think a gradual throughput penalty is out of the question because it inevitably increases compute requirements by an unacceptable amount.

That is because the point of the new system is to treat the whole fluid network (or each of those 250x250 areas) as one big fluid box. That will dramatically decrease compute requirements. If you need to split up those big fluid boxes again to determine throughput for every pipe segment inside of them, you basically end up with the same problem as the 1.1 system when it comes to the amount of calculations required.

You don't need to create more fluid boxes. If a fluid box exceeds the magical 250x250 limit, a penalty to throughput could be applied to the entire box. You don't create additional boxes. You just limited how quickly it can fill/empty by a % modifier. That's one variable to store in memory per fluid box and that same variable to multiply your fluid input/output speed by. i.e. fillRate becomes fillRate*modifier. It's really not a performance issue, if it is decided to go this route.

[Loewchen]

You don't need to create more fluid boxes. If a fluid box exceeds the magical 250x250 limit,

Fluid boxes are for single entities only, I assume you mean fluid segments?