Friday Facts #430 - Drowning in Fluids

[GregoriusT]

I'd have preferred a number of pipe+tank entities instead of an area (or maybe I missed something crucial).

Honestly, kindof the same for me, with Underground Pipes counting as their length, and all the other things counting as the amount of Tiles they occupy. Where the Limit of Tiles should be put would ofcourse need balance testing.


What I really want to know is what the "fluid must flow" Mod (or whatever it was called with the giant Ducts), will do after this update.
The options I see are:
- inlet/outlet pumps that do 6000/s to and from a duct. (though might not be good enough)
- have the ducts just automatically split the fluid network into segments without needing a powered pump. (long duct pipelines would then be directional)
- have the ducts be on the upper layer, like Rail Bridges, so that Biters cannot walk into them and get angry.

[CrazyAmphibian]

this just seems lame. the old system wasn't perfect, but at least you can work around the challenge in a way that feels natural. barrels and tank cars already exist and are fine (barrels are a much more niche use case but aren't bad). The diminishing effectiveness of pipes was intuitive, but also rewarded players who could optimize their factory for space efficiency.
But where's the skill expression in this system? Where's the nuance and mechanical depth that made me love the game so much?

[catpig]

I was initially quite sceptical about the fluid changes, but I'm warming up to them now. (also: I agree that the old system was so unintuitive, especially with the ordering thing, that something absolutely had to be done)

[arson]

One thing I was thinking about the other day though was why can't pipes be similar to belts? Meaning why can't we just place them next to each other without having to worry about pipelines overlaping? Is it just a decision to mix up the gameplay a bit or is it technical?

To add to this, there is the great mod advanced fluid handling. Would be interesting to know what prevents the devs to use a mod like this.

Maybe they just don't want them to be too "easy" I'd guess. Since in vanilla there aren't that many locations in a typical base where you'd need a better pipe system. Obviously it would create nicer designs and make some things much easier/simpler but maybe they just don't want to do it for challenge reasons, or it could be a technical limitation, I don't know I'm not a dev lol

[un_ordinateur]

Instead of using a 250*250 bounding box as the limiting factor the number of pipe segments should be the relevant number. It is far more realistic (which I know is not that important in game design) but it being realistic also makes it more intuitive.

Also instead of either 100% or 0%, the output should be a function relative to the number of pipe segments. For example 100% for 1-50 segments and then dropping near 0% at 300 segments. It might be worth to consider counting underground pipes and fluid pipes as multiple segments to balance long distance pipelines with distribution pipelines.

With that system a player could decide how much throughput their pipeline needs and therefore how often they need to place pumps.

Like many other others here, I think this suggestion is better!

I generally like the new system (and the overlay: 10/10); but a hard cutoff seems very weird. Whatever critera is used to limit the size of the system should gradually decline the performance of the pipe network.

Total number of pipes entities in the system is a good basis, but I would also consider somthing like the farthest distance (along the pipes) between any 2 points of the piping system.)

[kirkbauer]

I don't like the 1.1 fluid system. For example the fact that underground pipes provide better throughout than above ground.

I didn't like the last 2.0 fluid announcement where you got better throughput with longer pipe runs than with shorter pipe runs (as I understood it). That's not intuitive and it seems broken. You should never be able to get better throughput than what a single pipe can carry.

I don't like this update because it just seems arbitrary. Fluid doesn't just stop flowing at 250 tiles.

My suggestion is to isolate every section of pipe, broken up by pumps, Ts, and buildings. So if you have two pumps connected by 100 pipes, there are three sections. Each pump is its own section and the 100 pipes are their own section. Then determine the maximum flow of each section. Pumps are obvious. The pipes should be inverse of the length. So one pipe is full flow, 100 pipes is somewhat lower flow. The game can cache the sections, the connections, and the max flow for each section.

Now, take all entities that want to push into a section, add up the amounts and figure out the percentage of each entity. So if one pump wants to push 100 and another wants to push 50, then that's 66% and 34%. Now take the max flow of the receiving segment and allocate based on those percentages.

Same thing when pulling from a section. Find out the proportional demand and then allocate the max flow to each entity.

[Danjen]

Oh yeah, one other thing I forgot to mention in a previous post.
I might be misremembering, but did the fluid barrels get removed? I know fluid trains are the way to go for bulk distance transport, but conceptually, I love the idea of using barrels and transporting those, since it feels more "industrial" if that makes sense. Not sure if it's so compatible with current fluid throughput though

[thermomug]

I'm trying to understand the new changes. So you are maxed at 6000/s throughput / max 5 pumps? So would BP below be a viable max flow fluid bus?

5 pumps x12 = 6000/s each line
5 lines x 6000/s = 30,000 throughput, each span 250 wide, each row offset.
https://factoriobin.com/post/pkigJQgn1-yEVUmv-EXPIRES

Hi and welcome to the forum

From what I understand, the 6000/s hardcoded limit applies per in/output. So you are NOT limited to 5 pumps, as these have a "soft" limit of 1200/s anyway. Btw you are not required to build 5 fluid lines in parallel, as they all "collapse" into the same fluid segment with shared capacity and fill level.
I think the 6000/s are more relevant in the context of the in/output factors based on fill level:
An empty segment will accept 6000/s per input maximum but output nothing.
An 25% filled segment will accept 4500/s per input maxium and spread 1500/s per output maximum.
50% -> 3000/s per input, 3000/s per output, and so on...

But still, these limits only should be relevant for quality production buildings, and the interconnections between fluid segments. Standart tier production buildings shouldn't be affected by this limit.

[M_Gargantua]

So I got to thinking about this and would like to propose a better solution than a geographically fixed size restriction. This is taking into account the other 2.0 QoL improvements we're seeing with belt segments and such. Ref https://factorio.com/blog/post/fff-416

Driving cases -
A segments maximum draw can only be achieved at 100% fill.
A segment will be filled proportionally from everything trying to add fluid into it, regardless of location.
A segment will be drawn upon up to the maximum limit proportionally from everything attempting to draw, regardless of location.
You shouldn't be able to infinitely add more pumps to force more fluid through.

Tick Draw Max = Maximum Draw * (Segment Fluid Quantity / Segment Volume)
Maximum Draw = 10 (or 0?) <= Inlet Limit * ( -0.28 *ln(N) + 1.65) <= Inlet Limit,
where N is the sum of pipe's and tank's have an N value of 10.
ln(N) could be a lookup table to save computation, and doesn't need to be recalculated often for segments, and can be stored when segments are added. This puts flow limit at 100% for N up to 10, and is effectively 0 at a distance of ~350

Inlet Limit = Either a fixed value or some equation (to prevent you from putting like 20 pumps into one pipe). eg 1200. or some number that keeps nuclear reactor scaling correct.



An example of how this ends up:
100 pipe segments and a tank has an N of 110, the segment flow is 401f/s, enough petroleum to feed 2 red belts of fully beaconed plastic. The sinks can't consume more than 401 without draining the pipe, and that slows down the consumption further until steady state is reached.

[thermomug]

I find a little disturbing that these two contraptions are equivalent

sorry for the big zoomed out picture

2024-09-27 20_28_54-Window.jpg

I'd have preferred a number of pipe+tank entities instead of an area (or maybe I missed something crucial).

I think both contraptions might be equal in terms of throughput to adjacent fluid segments at equilibrium (when fill levels are stable, meaning all input flows equal all output flows), but they are definitely not equal in capacity.

When introducing a fluid flow from one side (NOT the equilibrium case, like when a new oil train arrives at a starved factory), the segment with a higher capacity ( the right in your case ) will fill more slowly and thus also introduce a bigger temporal delay in the whole chain of segments. I think this might be what was meant by the devs with "the fluids feel[ing] much more like fluids again".

[apriori]

Am I correct in understanding new fluid system?

1. Pipe segment has unlimited flowrate between its pieces/parts.

2. Pipe segment is a solid «web of pipes» in a 250×250 square. These 6 «pipe webs»: l, L, F, E, H, T — are 6 pipe segments, if they're not larger than 250×250 each.

3. Storage tanks connected to a pipe segment are a part of that segment. They just act as pieces of that segment, like any other pipe in the segment. Even a linear sequence of pipe-tank-pipe is one solid pipe segment. Tank is not a machine, neither producer nor consumer — it's a huge pipe.

4. Storage capacity of one pipe segment equals: (<number-of-pipes-in-segment> × <pipe-capacity>) + (<number-of-tanks-in-segment> × <tank-capacity>).

5. If a segment is ALWAYS full of liquid, and:
5.1. If there's a liquid-hungry consuming machine connected to a pipe in the segment, the machine can consume at max flowrate of 100/tick.
5.2. If there're several machines, they can consume liquid at max flowrate of 100/tick EACH.

6. So, a machine consumes not from the pipe it's connected to, but from the whole segment.

7. If the segment ALWAYS contains liquid at 50% of its capacity, those machines can consume at max flowrate of 50/tick. So max flowrate provided by (any part of) segment to each individual consuming machine is 100 × <segment-capacity-usage> / <segment-capacity>; and if this number is more than actual max consumption rate of the machine, then the machine consumes at its max rate.

[TiMatic]

Am I correct in understanding new fluid system?

1. Pipe segment has unlimited flowrate between its pieces/parts.

2. Pipe segment is a solid «web of pipes» in a 250×250 square. These 6 «pipe webs»: l, L, F, E, H, T — are 6 pipe segments, if they're not larger than 250×250 each.

3. Storage tanks connected to a pipe segment are a part of that segment. They just act as pieces of that segment, like any other pipe in the segment. Even a linear sequence of pipe-tank-pipe is one solid pipe segment. Tank is not a machine, neither producer nor consumer — it's a huge pipe.

4. Storage capacity of one pipe segment equals: (<number-of-pipes-in-segment> × <pipe-capacity>) + (<number-of-tanks-in-segment> × <tank-capacity>).

5. If a segment is ALWAYS full of liquid, and:
5.1. If there's a liquid-hungry consuming machine connected to a pipe in the segment, the machine can consume at max flowrate of 100/tick.
5.2. If there're several machines, they can consume liquid at max flowrate of 100/tick EACH.

6. So, a machine consumes not from the pipe it's connected to, but from the whole segment.

7. If the segment ALWAYS contains liquid at 50% of its capacity, those machines can consume at max flowrate of 50/tick. So max flowrate provided by (any part of) segment to each individual consuming machine is 100 × <segment-capacity-usage> / <segment-capacity>; and if this number is more than actual max consumption rate of the machine, then the machine consumes at its max rate.

That's how I understood it too

[protocol_1903]

Posted this in Raiguard's discord, but I'll put it here to see what everyone thinks

What if the pipe limitation was a point-to-point limit instead of a square? Each pipe can only be (for example) 500 fluid boxes away from the furthest pipe before the network becomes invalid. I also thought of a decent implementation, only updating when a pipe is placed so there is no overhead on static bases. That way you can still have the compact networks of pipes, but can also drag a line of pipes further than 250 tiles and still be valid. It also gets around the spaghetti within 250 tiles being valid but not if it's stretched out, which just feels weird.

LMK what you think, and I can share the implementation if you want it.

[eloepp]

I know it's probably disheartening to see a lot of negativity for the devs, but I would be lying if I said this seemed like a good and interesting change (still not a huge fan of fluids 2.0 in general). But I guess I will not know 100% until I play SA.

As others have said, it seems random, arbitrary. I know realism isn't necessarily the goal, but all flow somehow ceasing is counterintuitive and just... weird. It feels like a band-aid fix.

the game telling me I need to put a pump somewhere doesn't seem fun. "Okay, thanks game, you did the thinking for me", but I want to figure stuff out, that's why we play Factorio! I want fluids to be a deep and interesting challenge, a problem to be solved, and I want to feel a sense of satisfaction when I figure it out, like "hey, look at my base, look at how I did fluids, look at how I overcame this obstacle".

I think part of the reason people are harsh and give strong feedback is that we have very high expectations for Wube, after all, Factorio is one of the best games ever made, and maybe one of the most highly optimized (just from what I've heard). It's always felt like the developers could solve any issue. I think it is a compliment that people are so passionate about this topic, even if the feedback is sometimes negative. I just hope that Wube will maintain consideration for the fluid system post 2.0 release.

[apriori]

I'd like to ask devs to change the behaviour of storage tanks and therefore pipes in a segment:

1. Tank has two internal storages: working and overflow ones. Working storage capacity is the same as a pipe capacity (or: <tank-square> × <pipe-capacity>, it's even better). Overflow storage capacity is: <tank-capacity> — <working-storage-capacity>.

2. When a tank is being filled, a working storage is being filled first, then an overflow storage.

3. When a tank is being emptied, an overflow storage is being emptied first, then a working storage.

4. Pipe segment has two storages as well. Its working storage capacity is a sum of pipes' capacities plus tanks' working capacities. Its overflow storage capacity is a sum of tanks' overflow storage capacities.

5. Pipe segment's storages behave the same way as a storage tank's ones do.

6. Flowrate between working and overflow storages is unlimited.

[7] Maybe it should be a separate overflow storage tank and it should have to be filled with pumps to get its overflow storage filled.

[Theikkru]

[...]What if the pipe limitation was a point-to-point limit instead of a square? Each pipe can only be (for example) 500 fluid boxes away from the furthest pipe before the network becomes invalid.[...]

This would be nice, but in the first fluid FFF, the devs mentioned that one of the motivations for the implementation of "pipe segments" was that they were trying to get away from the complexities (and associated calculation costs) involved in pathing through a pipe network with an arbitrary number of junctions. Even if those calculations only had to be done during construction/deconstruction, bots exist in Factorio, so...
That's why everyone's been suggesting the slightly less realistic but far more performant "just count the tiles in the pipe segment".

[CrazyAmphibian]

i suppose instead of just complaining i should offer solutions, too.
what if the 1.0 fluid system core was kept, but fluids are given inertia? it would solve the issue of longer pipe networks having lower flow rate but still keep the efficiency of short networks while maintaining player freedom to build as they please. This would make it so that long pipes would have latency (which would be expected from long ranges and is the case when moving solid materials on belts), but not as much of a throughput decrease. This would also keep the utility of existing tools like trains (long distance, high volume) and barrels (long distance, low volume, little setup)

[Theikkru]

[...]what if the 1.0 fluid system core was kept, but fluids are given inertia?[...]

The #1 reason the devs are reworking fluids is performance, so any idea that doesn't slash performance costs to a level comparable with what they've got in these FFFs is probably not gonna fly.

[georgebanjog]

I was really looking forward to the 2.0 fluid system.... But after this, I'd rather keep the old one... Only complicated everything, now it is not clear at all how it all should work, some restrictions on 250 blocks, some capacity limits, etc.

How about in the game settings, you can choose which system to play with?

[Eric_NL]

I personally don’t like input being adjusted by fill level. I like the idea of players being able to optimize their system with pump ratios to avoid starving machines, but I can see where others would like this new input adjustment system.

[...]a single heat exchanger outputs 103 units of steam per second per 10mw,
so you need 20 heat exchangers for 192mw, outputting 1977.6 units of steam per second.

If you did not pay attention up till here: 1977.6/s is actually more than 1200/s,
and breaking this apart in any other way, for an infinitely tile-able design would simply not just not work but also look extremely ugly while trying!

You forgot the part where steam machines now consume 1/10th of the water.

[...]What if the pipe limitation was a point-to-point limit instead of a square? Each pipe can only be (for example) 500 fluid boxes away from the furthest pipe before the network becomes invalid.[...]

Assuming the new fluid system uses an ID system for pipe segments, I don’t see why we can’t just limit the segments based on piece count. Unless the devs are specifically avoiding storage tank lines?