Nuclear Power Plant from the future

[Theikkru]

[...]I got Factorio in 2021, and I never got a different simple oil processing than what it is today.[...]I really don't understand why someone is angry about that.[...]

If you'd like to learn more, I've got plenty of references and info in the balance proposal thread I made, and it's still open for discussion. I won't go into detail here, though, so as not to de-rail the thread.

Based only on last week's FFF (today's not out yet (edit: and it didn't talk about fluids anyway)), placing a tank at the end of a pipeline and having a pump draw from it should exaggerate the "teleporting" aspect.

That make total sense and didn't occured to me, the tanks can be used not at the "high elevation" but at the "low elevation" regarding the water tower analogy. It would "attract" more water in absolute value each tick due to its individual capacity being larger than one a pipe. That's a thing i will test in game when possible !
[...]

It's not just that, but also that the devs specifically mentioned pumps pulling from storage tanks as a special case, so I presume they do something like reach maximum flow at a lower percentage of fill or some such. In combination with pipe snaking capacity etc., that means you'd probably only need as many tanks as are necessary to provide enough direct connection points for the pumps you want. In fact, you'd pretty much always want to deploy tank-to-pump setups to get maximum pumping effectiveness.

[Koub]

the devs specifically mentioned pumps pulling from storage tanks as a special case, so I presume they do something like reach maximum flow at a lower percentage of fill or some such. In combination with pipe snaking capacity etc., that means you'd probably only need as many tanks as are necessary to provide enough direct connection points for the pumps you want. In fact, you'd pretty much always want to deploy tank-to-pump setups to get maximum pumping effectiveness.

That's what I understood too. Optimal tank usage should be limited to "as many as needed for downstream usage", and be drawn from by a pump.

[mmmPI]

It's not just that, but also that the devs specifically mentioned pumps pulling from storage tanks as a special case, so I presume they do something like reach maximum flow at a lower percentage of fill or some such. In combination with pipe snaking capacity etc., that means you'd probably only need as many tanks as are necessary to provide enough direct connection points for the pumps you want. In fact, you'd pretty much always want to deploy tank-to-pump setups to get maximum pumping effectiveness.

I've been thinking about that, currently there is already a "higher max throughput" when you use pump to get liquid out of tank that i understand as : not more than the capacity of 1 entity can be transfered each tick. Meaning that for pipes it's 100 fluid per tick, ( 6000 /s) whereas for tanks, there is no "limit" due to this phenomenon but rather a limitation on the pump speed ( 12000 /s ).

I wonder if this kind of thing will still be at play, with the "teleporting" liquid, it seem like they can teleport from source to destination, but i'm not sure what would be the "source" if you have a 4 tanks connected together, holding 100K fluid, and a pump extracting fluid from 1 of the tank, to transfer it into another group of 4 tanks. I suppose in such cases, only 12K fluid will be transfered per second. ( 200 per ticks).

But then when the group of source tank run low, their level will balance to say 50 fluid in each tank. Will the pump push the 200 remaining fluid all at once ? Or only be able to extract 50 per tick as it's the quantity of fluid in the "directly" connected tank ?

tank to pump setup are what i use for train stations, but i thought the update meant it won't be as "necessary" as it used to be, i'd WANT to avoid deploying tank to pump setup everywhere, even if it's max pumping effectiveness, i wasn't feeling compelled to do so before the update, only in rare places that really needed it, mostly for non-optimized builds. Supposedly it will be easier in the future to deal with fluid, so i think players are also meant to be able to avoid placing pump everywhere, as a design choice, even if it means skipping on the fastest transfer speed. But i'm not sure if it's the case.

In my previous example, it would mean the pump extract the max amount of fluid in a single tick from the whole network (200 and not just 50 from the tank it is directly connected to ) ( super easy mode and different from current reason that tank=>pump=>tank have higher thoughput than with pipes). Again not sure what will be the "special case".

[Theikkru]

I think you're getting hung up on the old idea of pipes/tanks having their own properties. In the FFF they showed individual flow rate and capacity bars on each tank or piece of pipe, but under the new system, there's no such concept; all pipes and tanks connected contiguously will share the same "pool" of fluid.
It's not so much that fluids are teleporting from one end of the pipe to the other, as it is that there just isn't any concept of distance or separation between points along a "pipe segment". In other words, the "source" of fluid you are pumping out of (or the destination you're pumping into, for that matter,) will no longer ever be a particular pipe or a tank, but the "pipe segment" as a whole. Whether a pump is intaking from a pipe piece or a tank is only relevant in determining whether it gets the special case bonus to flow; all other properties of that individual pipe or tank are irrelevant.
Using your example of 4 full tanks (100kfluid) pumping into 4 other tanks, and assuming a pump rating of 12000fluid/s, and that the tank-pump bonus is something like max flow until 50% fill, then you can expect max flow (-12000fluid/s) for the first ~4.167 seconds, after which it would decrease according to f=-12000e^(-t+4.167). If you were to stick a pipe in between the pump and tank instead, your flow would just be f=-12000e^(-t), so just a lot worse throughput all around.
P.S. I'm probably missing a constant factor for t in those equations due to lazy calculus, but the idea's there.

[mmmPI]

I think you're getting hung up on the old idea of pipes/tanks having their own properties. In the FFF they showed individual flow rate and capacity bars on each tank or piece of pipe, but under the new system, there's no such concept; all pipes and tanks connected contiguously will share the same "pool" of fluid.
It's not so much that fluids are teleporting from one end of the pipe to the other, as it is that there just isn't any concept of distance or separation between points along a "pipe segment".

It may be true that i'm not able to picture properly the new system, that's part of why i made this post.

This particular video from the FFF, is what i called "fluid teleporting" in the "last pipe of the snake", as i supposed it would also act in my nuclear power plant, where the steam or water will reach all turbines at the same time.


It appears to me that there IS a concept of "individual" properties. The tank being still 25K capacity and not into the same group as the "snake of pipe". both being separated by a pump making them seemingly 2 "segment" where the "quantity inside the snake of pipe" can be "decreasing" whereas the "quantity in the last tank" would be "increasing" in the last few seconds of the videos.

In other words, the "source" of fluid you are pumping out of (or the destination you're pumping into, for that matter,) will no longer ever be a particular pipe or a tank, but the "pipe segment" as a whole. Whether a pump is intaking from a pipe piece or a tank is only relevant in determining whether it gets the special case bonus to flow; all other properties of that individual pipe or tank are irrelevant.

In such case, my design as posted on the first page would work "better" without any pumps at all, than with 1 single pump. ( considering the single pump "cut" the segment into 2 following my interpretation of the previous video). That seem counter-intuitive to me.

Using your example of 4 full tanks (100kfluid) pumping into 4 other tanks, and assuming a pump rating of 12000fluid/s, and that the tank-pump bonus is something like max flow until 50% fill, then you can expect max flow (-12000fluid/s) for the first ~4.167 seconds, after which it would decrease according to f=-12000e^(-t+4.167). If you were to stick a pipe in between the pump and tank instead, your flow would just be f=-12000e^(-t), so just a lot worse throughput all around.
P.S. I'm probably missing a constant factor for t in those equations due to lazy calculus, but the idea's there.

This i don't understand/follow your reasonning anymore, this is part of what is puzzling me, if the "pump" DO NOT separate the segment, as it seem to me you suggested earlier , then 4 tanks => pump => 4 tanks, should be considered a single "fluid box"/"segment" as soon as the pump is open to me.

It seem counter-intuitive that the pump would not be the determining factor for the speed at which the liquid is transfered in that if instead of a pump you'd place a pipe to make it 4 tanks => pipe => 4 tanks, it seem to me that your calculus for flow would also apply. ( since it's entirely based on difference of quantity of fluid ).

I may be doing mistake of interpretations x), i think many players are too because it seems to me that players understood the FFF quite differently.

[Theikkru]

[...]


It appears to me that there IS a concept of "individual" properties. The tank being still 25K capacity and not into the same group as the "snake of pipe". both being separated by a pump making them seemingly 2 "segment" where the "quantity inside the snake of pipe" can be "decreasing" whereas the "quantity in the last tank" would be "increasing" in the last few seconds of the videos.

Numerically, this understanding is correct: there are two pipe segments with those properties. However, what's relevant for flow calculations is the properties of the two pipe segments, and not the properties of the individual components within those segments. It just so happens that the second pipe segment in that example consists of only 1 tank, so it shares the same properties as that tank. If you were to connect another piece of pipe to that tank, the properties of the segment would change to include that piece of pipe, and the properties of the individual tank would cease to be relevant.

In other words, the "source" of fluid you are pumping out of (or the destination you're pumping into, for that matter,) will no longer ever be a particular pipe or a tank, but the "pipe segment" as a whole. Whether a pump is intaking from a pipe piece or a tank is only relevant in determining whether it gets the special case bonus to flow; all other properties of that individual pipe or tank are irrelevant.

In such case, my design as posted on the first page would work "better" without any pumps at all, than with 1 single pump. ( considering the single pump "cut" the segment into 2 following my interpretation of the previous video). That seem counter-intuitive to me.

Counterintuitive as it may seem, that is the behavior of the new rules. Eliminating extraneous tanks would also help the pipe segment fill faster by decreasing the pipe segment capacity, which would help increase flow. Conversely, tanks directly before pumps would help flow despite increasing pipe segment capacity, because of the special case.

Using your example of 4 full tanks[...]

This i don't understand/follow your reasonning anymore, this is part of what is puzzling me, if the "pump" DO NOT separate the segment, as it seem to me you suggested earlier , then 4 tanks => pump => 4 tanks, should be considered a single "fluid box"/"segment" as soon as the pump is open to me.
[...]

The pump does separate pipe segments. My calculations are based on a pump max flow rating of 12000fluid/s.

[...]if instead of a pump you'd place a pipe to make it 4 tanks => pipe => 4 tanks, it seem to me that your calculus for flow would also apply. ( since it's entirely based on difference of quantity of fluid ).

That calculus would not apply if a pipe piece were connecting instead of a pump, because there is no flow within a pipe segment: the entire segment shares the same fluid. In addition, those calculations are only dependent on the max rating of the pump, and the percentage fill of the source pipe segment; there is no "difference of quantity of fluid". The amount of fluid in a destination pipe segment is only relevant if it's 100% and stops flow entirely.

[mmmPI]

Counterintuitive as it may seem, that is the behavior of the new rules.

I think i understand better what you meant, i had missed some details earlier, and you seem convinced about your description, but i cannot be convinced that "easily"

Considering the situation where 4 tanks are filled with water, and 4 tanks are empty next to it. Connecting the 2 fluid system with a pump (suddenly) may lead to the situation you describe. (For reasonning purposes i will agree). But if you connect them with a pipe instead. Then there is only 1 segment with 8 tanks and a pipe in the middle. There will be "fluid transfer" in between different entities from the same fluid network containing different quantity of fluid relative to their capacity. no ?

( from the pipe to the tanks or from some tanks to other tanks "through" that connecting pipe ).

Conversely, tanks directly before pumps would help flow despite increasing pipe segment capacity, because of the special case.

This seem to me problematic. As if you don't use the pump at all, the "flow" would be "even better". Otherwise, the "pump" would act as the bottleneck, with a flow capped at 12K/s whereas there would be no cap for a network in a single segment. ( in the power plant design, this means i shouldn't use any pumps at all between the offshore pumps and the heat exchangers.)

Using a single pump would cap the water intake at 12K/s from my understanding of what you described, and 3 pumps 36K/s. So my design would only work without pumps, or with 3 + pumps , but if using a single one it would be "worse" than with 0 pumps ? ( i repeat how counter-intuitive that seem to me, the situation being slightly different than previously mentionned).

( this is related to the first case, the "fluid transfer in between different entities from the same fluid network", in that if instead of 4 tanks on each side there was 400 tanks, the fluid level reaching equilibrium overtime would cause a "flow" of much much higher value through a single pipe than through a pump according to how i understand your explanation. this seem to be not consistent with the idea that pump and tank working together are a "special case" for high throughput , if the "max" possible flow means not using pumps and could be achieved with only pipes)

I don't know for sure where you would leave some margin for the "thoughput numbers" to be tweaked as said in the FFF. And i don't have a more consistent explanation of what i think the "new" rules are. But i am not convinced by your explanations, not saying you are wrong, just that it's part of what "may be" for me, it's an "hypothesis" that leaves almost no un-answered question. Almost ... ^^ But it is not enough for me to exclude in a categoric manner that there could still be misunderstanding or things we missed/weren't told yet. ( i would say you have "convinced" me otherwise ).

[Panzerknacker]

[Moderated by Koub, please refrain from trolling. If you have nothing constructive to tell, don't say anything.]

[Theikkru]

I think there is a key detail you are missing that relates to this rule in the FFF:

Machines can push fluid into a segment at an unlimited rate, and can pull from a segment at a rate proportional to how full the segment is. In other words, if a segment is half full, then the pulling rate is half of the maximum.

---

[...]
Considering the situation where 4 tanks are filled with water, and 4 tanks are empty next to it. Connecting the 2 fluid system with a pump (suddenly) may lead to the situation you describe. (For reasonning purposes i will agree). But if you connect them with a pipe instead. Then there is only 1 segment with 8 tanks and a pipe in the middle. There will be "fluid transfer" in between different entities from the same fluid network containing different quantity of fluid relative to their capacity. no ?

No. You need to discard the idea that there is fluid in those individual entities, and understand that fluid only exists in the pipe segment as a whole. By connecting the two tank sets with pipes, you are merging two pipe segments into one, irreversibly, causing all properties across that segment to instantly become one and the same, based on merging calculations; that's not really "flow" or "transfer". (This distinction is important later.) If you then remove one of those pipes, you are then simply dividing the one segment into two, with equal fill percentages.

This seem to me problematic. As if you don't use the pump at all, the "flow" would be "even better". Otherwise, the "pump" would act as the bottleneck, with a flow capped at 12K/s whereas there would be no cap for a network in a single segment. ( in the power plant design, this means i shouldn't use any pumps at all between the offshore pumps and the heat exchangers.)

Using a single pump would cap the water intake at 12K/s from my understanding of what you described, and 3 pumps 36K/s. So my design would only work without pumps, or with 3 + pumps , but if using a single one it would be "worse" than with 0 pumps ? ( i repeat how counter-intuitive that seem to me, the situation being slightly different than previously mentionned).
[...]

Here is the problem: for fluid to be useful, it must ultimately leave a pipe segment and enter some other entity to be used (e.g. turbines, chemical plants). Therefore, there will always be a "machine" (governed by the FFF rule that I quoted above) at the end of a pipe system. It is useless to discuss "flow" or "fluid transfer" within pipe segments, because the limiting factor will always be downstream of that pipe segment.
In the case of 0 pumps in your power plant example, flow would remain at max rate so long as the pipes remain 100% full, but as soon as they fall below that fill level, the machines trying to extract from them (whether that be turbines or heat exchangers) would start to lose performance. In other words, there must always be a volume of fluid equal to the capacity of the pipe segment trapped in that pipe segment in order for full flow to occur. This is why REDUCING the capacity of a given pipe segment is good.
If, however, you put a tank-pump arrangement as close as you can to the downstream "machines", you divide what was one pipe segment into two, with different properties: the first segment, with most of the capacity, that can be drawn down to a much lower fill level (50% in my calculus example) without compromising flow, while the second segment, with much smaller capacity, still must remain full. This effectively turns the first segment into a fluid buffer, and reduces the total volume of fluid required to run the pipe system effectively, especially over long distances (due to the increased capacity).

[mmmPI]

I think there is a key detail you are missing that relates to this rule in the FFF:

Machines can push fluid into a segment at an unlimited rate, and can pull from a segment at a rate proportional to how full the segment is. In other words, if a segment is half full, then the pulling rate is half of the maximum.

I have this in memory; but i don't understand how it should be interpreted in the case of "no machine" only tank and pipes and/or pumps. The "maximum" mentionned though i think understanding that's where you consider flow can only exist and as such would be the place where "tweaking numbers" is done. ( otherwise it's not "flow" for you as i understand the next quote).

No. You need to discard the idea that there is fluid in those individual entities, and understand that fluid only exists in the pipe segment as a whole. By connecting the two tank sets with pipes, you are merging two pipe segments into one, irreversibly, causing all properties across that segment to instantly become one and the same, based on merging calculations; that's not really "flow" or "transfer". (This distinction is important later.) If you then remove one of those pipes, you are then simply dividing the one segment into two, with equal fill percentages.

Well to me that is flow and transfer, i imagine the situation where on the left you have 4 filled tanks, and on the right 4 empty tanks , then i manually put a pipe to connect them, and have the game pause, and only go 1 tick at a time and considering the amount of "green bar" as shown in the FFF in every tanks.

Initial situation is indeed 2 segment , one empty , one full, then they are connected, but the level of water will not stay as 1 group full and 1 group empty, the "empty group" will have like shown in the FFF a "green bar" that will increase over time at a certain rate. no ?

I feel like it won't be instantaneous.( like in the FFF video when the pump is turned on, the green bar "increases" during a short duration in all the pipes )

Another way to think of it as flow (for me) would be to consider that you put the pipe in the middle and remove it after 1 or 5 or 10 or 20 ticks and compare the fluid quantity in the 2 different group of tanks. Then divide the quantity in the previously empty group of tanks by the amount of time during which a pipe was connecting the 2 groups. ( that's why i strike "irreversibly )

The part i underlined to me seem to suggest that you say the quantity after 1 or 5 or 10 or 20 ticks will be the same : 50% of what was initially in the group of tank that was filled. I think it is not correct because of the video shown in the FFF, but maybe you think it will be different if instead of turning a pump "on" it is a pipe that is placed ; since one is creating 2 segment and not the other ? That would be to me the thing counter intuitive, if you put a pump you create 2 segment and thus lower the rate of transfer compared to a single segment made of pipes.

What you describe to me would STILL be a "flow" , a flow of 50% of fluid contained in one segment, (tank 1 2 3 4 ) toward what was previously another segment ( tank 6 7 8 9 ) in a single tick. ( if adding pipe cause fluid level in the new segment made from the 2 old to be levelled immediatly upon unification and stay as is after the unificating pipe is removed the next tick).

Here is the problem: for fluid to be useful, it must ultimately leave a pipe segment and enter some other entity to be used (e.g. turbines, chemical plants). Therefore, there will always be a "machine" (governed by the FFF rule that I quoted above) at the end of a pipe system. It is useless to discuss "flow" or "fluid transfer" within pipe segments, because the limiting factor will always be downstream of that pipe segment.

That's another thing x) I have seen fluid going IN AND OUT of entities in the past, i think it can still happen in vanilla with the boilers when you put them inline that the quantity of water in a single one goes up and down a little before settling. Not sure how it will be in the future.

I understand when you say the limiting factor will always be downsteam of that pipe segment but depending on previous situation, i'm not sure it will be the case all the time. Considering the picture of the FFF, if the pump in the snake of pipe is only turned on 1 tick every other tick, the "throughput" will be 6000 fluid per second. If you have 60 heat exchanger, they would require more than 6000/S.

As i see it the "pump" itself could become the limiting factor in the design i posted. Thus i would need, while building, to keep track of how many "connexions" exist between the segment that contain all the offshore pumps ( pushing water at infinite rate). And the segment that contain all the heat exchanger. ( pulling at a limited rate based on fluid % OR/AND pulling at a certain rate due to the machine receipe/normal consumption).

It could happen that my offshore pumps segment and the heat exchanger segment need "more flow" between them no ? so that the segment of fluid containing the heat exchanger receive more water via the pump from the other segment with the offshore pumps than the consumption of the heat exchanger when their segment is full and their work at full capacity would be.

If ( 1 pump => 12K fluid/s but 150 heat exchanger => around 15K/s consumption) = I need more pumps between the 2 segments ?

I dont this it's useless to discuss flow, but there are many things like that, where (many) other people think it's useless to discuss but not me; It's quite subjective

In the case of 0 pumps in your power plant example, flow would remain at max rate so long as the pipes remain 100% full, but as soon as they fall below that fill level, the machines trying to extract from them (whether that be turbines or heat exchangers) would start to lose performance. In other words, there must always be a volume of fluid equal to the capacity of the pipe segment trapped in that pipe segment in order for full flow to occur. This is why REDUCING the capacity of a given pipe segment is good.

I understand the first part, but i don't necessarily draw the same conclusion or at least i add nuances/reserve for special cases.

It seem to me that If you want the better flow, you also need the larger segment, because the quantity of fluid in absolute value that can be pulled from any segment while keeping the machine connected to it running at 100% is larger for larger segment, you can use more machines at the same time, which means somehow you have more 'useful' flow.

Yes you need the segment filled with fluid for better flow ( not 10% filled), AND you need that segment to be the highest capacity possible for better flow. ( i think) Hence why i said my power plant could work better with 0 pumps between offshore pumps and heat exchanger. That segment capacity would be hugeee, so all the heat exchanger "consuming their tick consumption" would still not be significant regarding the fullness or not of the segment which would make it "immune" to flow reduction.

It's going into niche case that cannot really be demonstrated in game but to explain when it's not "immune" i could think of a segment that is composed of :
-a single pipe
-6 offshore pumps connected to it ( impossible in game)
- a pump exctracting fluid from that single pipe to put into a tank.

Offshore pump produce 20 fluid per tick, so if there was 6 connected to a single pipe, they wouldn't be able to produce 120 fluid per tick, since pipe can only hold 100.
Similar situation but maybe more plausible in game may occur if you use not offshore pumps (because you need 6 to exceed a pipe's capacity) but regular pumps and a "too small segment" for the expected quantity of "fluid turnover" occuring every tick.

Given that real pumps can push 6000 or 12000 fluid per second, that is 100 or 200 per tick, if "a segment of fluid" is composed of 10 pipes, and 10 pumps are attempting to push fluid, and 10 other attempting to pull. Wouldn't it mean that doublling the amount of "pipes" in the network would allow more transfer ?

In some more general perspective that would be asking :

Why would transfering to "tank" be so much better if now pipes are not having a "100" individual capacity anymore ? As that was what limited their transfer rate for me.

( asking to anyone including myself this is not a trap x) )

If, however, you put a tank-pump arrangement as close as you can to the downstream "machines", you divide what was one pipe segment into two, with different properties: the first segment, with most of the capacity, that can be drawn down to a much lower fill level (50% in my calculus example) without compromising flow, while the second segment, with much smaller capacity, still must remain full. This effectively turns the first segment into a fluid buffer, and reduces the total volume of fluid required to run the pipe system effectively, especially over long distances (due to the increased capacity).

That's not what i had in mind when designing the power plant. I think that make sense considering what you said earlier, as a logical consequence, but i am not so sure i agree / understand the previous step.

Anyway it's interesting to read, it make me think about different strat to test, and consider i could have misunderstood things

[Theikkru]

I think there is a key detail you are missing that relates to this rule in the FFF:

Machines can push fluid into a segment at an unlimited rate, and can pull from a segment at a rate proportional to how full the segment is. In other words, if a segment is half full, then the pulling rate is half of the maximum.

I have this in memory; but i don't understand how it should be interpreted in the case of "no machine" only tank and pipes and/or pumps.[...]

In the absence of machines, (note: pumps are machines,) the following rules apply:

Pipes, underground pipes, and storage tanks are merged into fluid "segments".
Each segment inherits its volume from the fluid boxes that comprise it and can hold one fluid.
[...]
There is no longer a realistic fluid "flow" through pipes; fluid pushed to a segment will be immediately available at any point along a segment.

---

[...]i imagine the situation where on the left you have 4 filled tanks, and on the right 4 empty tanks , then i manually put a pipe to connect them, and have the game pause, and only go 1 tick at a time and considering the amount of "green bar" as shown in the FFF in every tanks.

Initial situation is indeed 2 segment , one empty , one full, then they are connected, but the level of water will not stay as 1 group full and 1 group empty, the "empty group" will have like shown in the FFF a "green bar" that will increase over time at a certain rate. no ?

I feel like it won't be instantaneous.( like in the FFF video when the pump is turned on, the green bar "increases" during a short duration in all the pipes )

No; it will be instantaneous. (See the third rule above.) The FFF video takes time because the pump is a machine transferring/flowing between two segments, not merging two segments into one.

[...]
What you describe to me would STILL be a "flow" , a flow of 50% of fluid contained in one segment, (tank 1 2 3 4 ) toward what was previously another segment ( tank 6 7 8 9 ) in a single tick. ( if adding pipe cause fluid level in the new segment made from the 2 old to be levelled immediatly upon unification and stay as is after the unificating pipe is removed the next tick).

I don't consider that useful terminology, because regardless of the shenanigans you do with merging and splitting pipe segments, the only transfer/flow that really matters is when you use a machine to transfer the fluid out of one of those pipe segments for use, in which case all the calculations and rules described earlier apply.

That's another thing x) I have seen fluid going IN AND OUT of entities in the past, i think it can still happen in vanilla with the boilers when you put them inline that the quantity of water in a single one goes up and down a little before settling. Not sure how it will be in the future.

I suspect that devices that can pass through fluids (like boilers and turbines) will behave like a pipe with a machine stuck to it, i.e. they will become part of the pipe segment for fluid passthrough, but will behave like a machine for actual fluid use.

I understand when you say the limiting factor will always be downsteam of that pipe segment but depending on previous situation, i'm not sure it will be the case all the time. Considering the picture of the FFF, if the pump in the snake of pipe is only turned on 1 tick every other tick, the "throughput" will be 6000 fluid per second. If you have 60 heat exchanger, they would require more than 6000/S.
[...]
If ( 1 pump => 12K fluid/s but 150 heat exchanger => around 15K/s consumption) = I need more pumps between the 2 segments ?

I dont this it's useless to discuss flow, but there are many things like that, where (many) other people think it's useless to discuss but not me; It's quite subjective

You are correct that the calculations regarding differing flow rates between various machines along a pipe system are important, but you have missed the point. My statement was:

[...]
It is useless to discuss "flow" or "fluid transfer" within pipe segments, because the limiting factor will always be downstream of that pipe segment.
[...]

That was referring to what you called "flow" or "transfer" when merging fluid segments. My point was that such shenanigans occurring within and between pipe segments alone are pointless, because the only part that matters is when fluid flows out to machines (such as the pumps, heat exchangers, and offshore pumps you brought up).

[...]
It seem to me that If you want the better flow, you also need the larger segment, because the quantity of fluid in absolute value that can be pulled from any segment while keeping the machine connected to it running at 100% is larger for larger segment, you can use more machines at the same time, which means somehow you have more 'useful' flow.

I'm not convinced that limitation exists; I see no reason the calculations cannot first determine how much fluid is trying to be deposited into the pipe segment from upstream sources, then determine the intended draw from downstream sinks based on current segment fill, and then pass the fluid through without changing the value of fluid in the segment if the two are equal.
In any case, even if such a limitation existed, it would be very superficial in nature, since two pieces of pipe would be enough to handle one pump-tick of fluid, and any practical scenario is going to require more than that in piping just to make useful connections between said pumps and other useful machines.

Yes you need the segment filled with fluid for better flow ( not 10% filled), AND you need that segment to be the highest capacity possible for better flow.[...]That segment capacity would be hugeee, so all the heat exchanger "consuming their tick consumption" would still not be significant regarding the fullness or not of the segment which would make it "immune" to flow reduction.

I'm not seeing how a higher capacity would help at all, (besides the bare minimum required to satisfy the potential limitation above,) or how tick-per-tick consumption would have anything to do with the fullness of the pipe segment, unless fluid input into the segment is overall lower than output from the segment. I don't understand what you mean by "immune" to flow reduction, since reduction would occur if, and only if, the pipe segment is less than 100% full.

It's going into niche case that cannot really be demonstrated in game but to explain when it's not "immune" i could think of a segment that is composed of :
-a single pipe
-6 offshore pumps connected to it ( impossible in game)
- a pump exctracting fluid from that single pipe to put into a tank.

Offshore pump produce 20 fluid per tick, so if there was 6 connected to a single pipe, they wouldn't be able to produce 120 fluid per tick, since pipe can only hold 100.
Similar situation but maybe more plausible in game may occur if you use not offshore pumps (because you need 6 to exceed a pipe's capacity) but regular pumps and a "too small segment" for the expected quantity of "fluid turnover" occuring every tick.

Given that real pumps can push 6000 or 12000 fluid per second, that is 100 or 200 per tick, if "a segment of fluid" is composed of 10 pipes, and 10 pumps are attempting to push fluid, and 10 other attempting to pull. Wouldn't it mean that doublling the amount of "pipes" in the network would allow more transfer ?

This is what I mean by not occurring in real scenarios: your first example requires breaking game geometry, and the second, while technically a valid example, serves no practical purpose; there is no point to the second set of pumps.

In some more general perspective that would be asking :

Why would transfering to "tank" be so much better if now pipes are not having a "100" individual capacity anymore ? As that was what limited their transfer rate for me.
[...]

It wouldn't be better. One of the points I was trying to make, originally, was that under the new system, pretty much the only place tanks are practical, is immediately upstream of a pump, to enable the special case.

[mmmPI]

Maybe this is somewhat inappropriate, i wouldn't do if it was sensitive matter, but i think in this case it is ok to quote some private messages that are part of this discussions ( let me know if i should remove them i tought it would help re-focus the discussion) :

[...]But if in new system all things are "merged" and a pump connected to a tank itself connected to another tank can "pull" from both tanks at the same time then a pump pulling from a pipe could also do the same no ?

Yes.

do you mean to say devs added a special behavior to interaction between pump and tank for a specific purpose ?

Yes. Otherwise, there would be no way to buffer fluids; you'd always want 100% segment fill for maximum flow.

This to me answer many questions about how you consider the fluid system that was revealed is to be understood.

I feel like it won't be instantaneous.( like in the FFF video when the pump is turned on, the green bar "increases" during a short duration in all the pipes )

No; it will be instantaneous. (See the third rule above.) The FFF video takes time because the pump is a machine transferring/flowing between two segments, not merging two segments into one.

That makes sense to me in that it is consistent with your other interpretation. I have hard time acknowledging it, and my intuitition is trying hard to find some mistakes in that reasonning, because i don't want to hear that fluid will behave this way, but i think you are sadly on the right side of interpretations there .... ^^

That was referring to what you called "flow" or "transfer" when merging fluid segments. My point was that such shenanigans occurring within and between pipe segments alone are pointless, because the only part that matters is when fluid flows out to machines (such as the pumps, heat exchangers, and offshore pumps you brought up).

From a gameplay perspective i understand that it is pointless figures to have, it would be figures of "flow" or "transfer" that i would have used to compared the "old" and "new" system to highlight the "max" throughput that was possible with the "old" and the "new". And how "pumps" are "worse" than "pipe" for "flow" in certain conditions when they would cut a segment in 2 segments limiting the "flow" from one to another, ( to 12K/S +/- adjustement related to fill-level) versus "unlimited" when a pipe is used.

I'm not convinced that limitation exists; I see no reason the calculations cannot first determine how much fluid is trying to be deposited into the pipe segment from upstream sources, then determine the intended draw from downstream sinks based on current segment fill, and then pass the fluid through without changing the value of fluid in the segment if the two are equal.
In any case, even if such a limitation existed, it would be very superficial in nature, since two pieces of pipe would be enough to handle one pump-tick of fluid, and any practical scenario is going to require more than that in piping just to make useful connections between said pumps and other useful machines.

I'm not seeing how a higher capacity would help at all, (besides the bare minimum required to satisfy the potential limitation above,)

This i think is answered by the PM i quoted at first, i was not sure how to consider "those limitations above". In my mind the current "special case" for pumps pulling from a tank is due to the "higher" capacity of the tank versus the pipe ( 100 fluid for a pipe is the max that can be "transfered" each tick" capping it at 6K/S). I understand that in your explanations, this is no longer the case, as a pump will be able to pull not only from the pipe to which it is attached, but from the whole segment ( and thus be able to pull more than "100" fluid per tick). This is still a bit puzzling, because you also say that tank will still be a "special case" of "higher throughput". Which can make sense if devs made something particular for it as you seem to believe. ( i can understand the tank is made "better" on purpose , but the "pipes" could also allow more than 6k/s fluid transfer (potentially) if pump is allowed to pull from the whole segment and not the single 100 capacity pipe no ?

This is what I mean by not occurring in real scenarios: your first example requires breaking game geometry, and the second, while technically a valid example, serves no practical purpose; there is no point to the second set of pumps.

I agree it's not real scenario, it was more "thought experiment" to invent an illustrating case where one or another intepretation would yield very different results so that it's easier to understand what is one's interpretation. I send PM afterward because i realized i may have not been clear when saying it. I think i understand how you say pump are going to work. That would mean for the power plant that "no pumps" is better than 1 or 3 pumps where i used 3. Which i dislike from gameplay logic.

It wouldn't be better. One of the points I was trying to make, originally, was that under the new system, pretty much the only place tanks are practical, is immediately upstream of a pump, to enable the special case.

I understand your reasonning i think. But i'm not sure how to explain why "pipes" would not have "unlimited" pulling rate when a pump is connected and the pipe and its segment is "full of fluid". ( pump pulling from tank is "special case", but why the "regular logic" when applied to pipes, yield a lower throughput ? ( if pumps are allowed to pull not only from the pipe to which they are attached, but from the whole segment).

I feel this is little details of math, but those are what need to be fully understood to design perfect power plant, it probably will feel MUCH MUCH simpler when the system is released and things can be measured/tested, but from this thread i will have a list of things to test and measure

[Theikkru]

[...]but i think in this case it is ok to quote some private messages that are part of this discussions[...]

It's fine.

[...]i can understand the tank is made "better" on purpose , but the "pipes" could also allow more than 6k/s fluid transfer (potentially) if pump is allowed to pull from the whole segment and not the single 100 capacity pipe no ?

Yes, they could.

[...]That would mean for the power plant that "no pumps" is better than 1 or 3 pumps where i used 3. Which i dislike from gameplay logic.

That would remain true only if the pipes stay full at all times. If the pipes end up less than full at some point, then depending on the respective machine flows, the pumps could help keep the second segment "pressurized" to full, even while the first segment is slack-filled, which would result in higher exit flow.
This is why I keep insisting that you have to include the machine(s) downstream of any pipe segments in your considerations: because that is what will ultimately become a critical limiting factor.

[...]
I understand your reasonning i think. But i'm not sure how to explain why "pipes" would not have "unlimited" pulling rate when a pump is connected and the pipe and its segment is "full of fluid". ( pump pulling from tank is "special case", but why the "regular logic" when applied to pipes, yield a lower throughput ?[...]

Because pipes (and other "pipe segment" constituents) don't "pull"; they just provide a connection point for the segment's fluid. It's always the downstream machine (in this case the pump) that defines the limit on flow through and out of a given pipe segment, and when connected to a pipe, the pump would be limited to its nominal max flow rate (and any reductions to that due to fill percentage of the segment).
Note: As I interpreted the "tank-pump flow bonus special case" to be an ability to reach max flow at lower fill percentages, there would be no difference between pipe-pump and tank-pump flow at 100% segment fill. That interpretation, however, is an assumption on my part: it is possible that the devs intend to implement that special case in a different manner, (such as a flat increase to the pump's max flow statistic,) in which case different behavior would be expected.

[mmmPI]

[...]That would mean for the power plant that "no pumps" is better than 1 or 3 pumps where i used 3. Which i dislike from gameplay logic.

That would remain true only if the pipes stay full at all times. If the pipes end up less than full at some point, then depending on the respective machine flows, the pumps could help keep the second segment "pressurized" to full, even while the first segment is slack-filled, which would result in higher exit flow.

This i understand what you mean i think now.

This is why I keep insisting that you have to include the machine(s) downstream of any pipe segments in your considerations: because that is what will ultimately become a critical limiting factor.

For my power plant ,i think that would translate as => i would consider heat exchanger cannot consume as much as 104 water per second, and have enough offshore pumps so that the pipe necessarily stays full at all time. So i would remove the tanks and the pumps that contain water to make it a single huge segment with the 2nd picture. That seem pretty boring, and the 1 pipeline-for-all-thing . This seem like it could be resumed as [input] / [pipe-segment/magic-box] / [output]. As long as it's a single segment.

Then for steam, the same reasonning could apply, while making sure the turbines can only consume less steam than what is produced per the combined amout of heat exchanger.

But then in doing so ( without pumps and only 2 segments) , it would not make sense to add tanks in the steam segment as buffer, because those when depleting in their regular role of buffer could cause the steam segmet of pipe to be less than 100%, obvisouly, which may hinder the rate at which the turbine can consume steam, and cause a power drop ?

Adding pumps for control of fluid flow was something i did with my nuclear plant sometimes, not only control of fuel, but both control method would yield less-than-full pipes in regular operation, before the refuel is done, or when the steam buffer is low. It gets more complicated when it's not only speculation on wether or not we understood the same things when reading the rules, but also on how we would apply it to actually make a power plant, i realize now about this thread

Because pipes (and other "pipe segment" constituents) don't "pull"; they just provide a connection point for the segment's fluid. It's always the downstream machine (in this case the pump) that defines the limit on flow through and out of a given pipe segment, and when connected to a pipe, the pump would be limited to its nominal max flow rate (and any reductions to that due to fill percentage of the segment).

That wasn't my question, but i like the answer, it makes it even clearer to have it said again differently, i probably missused the word "pull" and wasn't very clear in my words and understanding.

Note: As I interpreted the "tank-pump flow bonus special case" to be an ability to reach max flow at lower fill percentages, there would be no difference between pipe-pump and tank-pump flow at 100% segment fill. That interpretation, however, is an assumption on my part: it is possible that the devs intend to implement that special case in a different manner, (such as a flat increase to the pump's max flow statistic,) in which case different behavior would be expected.

This was what i meant to question. The detail that was/is continuing to puzzle me. One of the thing that is on the list of things to measure for when i can play the expansion
I may be wrong but maybe the fluid segment contain fluid as a whole which is then distributed into every entity based on its volume, => pipe 100 tanks 25000 ,which is then the cause for the "optimal case" being pump-to-tanks compared to pump-to-pipes. That wouldn't be simulating fluid "flow" from and into every single different entity. Instead i think that could be some sort of necessary calculation done only once per entity having a different volume in the segment, because they would all have the same amount of fluid (all pipes / all tanks / modded-tank ) , and used to limit the rate at which machine can pull in case of less than full segment from the particular entity to which it is attached based on its amount of fluid in absolute value.
That would explain without special treatment why tanks yield optimat transfer rate when used with pumps. ( and give me some feel that the fluid system still try to mimick the behavior of fluid as mentionned in the FFF, and so despite not simulating fluid itself)

[Theikkru]

[...]
I may be wrong but maybe the fluid segment contain fluid as a whole which is then distributed into every entity based on its volume, => pipe 100 tanks 25000 ,which is then the cause for the "optimal case" being pump-to-tanks compared to pump-to-pipes. That wouldn't be simulating fluid "flow" from and into every single different entity. Instead i think that could be some sort of necessary calculation done only once per entity having a different volume in the segment, because they would all have the same amount of fluid (all pipes / all tanks / modded-tank ) , and used to limit the rate at which machine can pull in case of less than full segment from the particular entity to which it is attached based on its amount of fluid in absolute value.
That would explain without special treatment why tanks yield optimat transfer rate when used with pumps. ( and give me some feel that the fluid system still try to mimick the behavior of fluid as mentionned in the FFF, and so despite not simulating fluid itself)

That would be a neat explanation for most of the behavior, (and would duplicate the behavior of my assumption about the tank-pump bonus without having to rely on an explicit special case,) but, unfortunately, the following part of the FFF seems to directly contradict it:

[...]
In the new system, junctions are entirely unimportant; a segment only cares about the machines connected to it. When a machine is updated, its max pulling rate is limited based on the filled ratio of the connected segment.
[...]

If your explanation were to apply, then multiple machines trying to pull from the same junction pipe piece would have a max pulling rate limited by the absolute value of the fluid in that individual junction pipe piece. That does not appear to be the case. In fact, the only mention of the volume of individual pipe/tank pieces in the entire FFF is in the section describing how they are merged to form a segment.

[mmmPI]

If your explanation were to apply, then multiple machines trying to pull from the same junction pipe piece would have a max pulling rate limited by the absolute value of the fluid in that individual junction pipe piece.

Yes, that would have been the idea, junction or not actually, just a single strech of pipe with 2 consumer connected on the last one would have given them both half the max potential pulling rate compared to having them offset by 1 pipe so they do not attempt to pull from the same, and so no matter the length of the pipe.

It could be a symbolic quantity of fluid that can be transfered to every entity pulling from that pipe ,and next tick is removed for the quantity of the whole segment several time if needed. That would need to not exceed the total quantity of fluid in the whole segment to not "generate fluid". If a pipe can hold 100 fluid, max pulling rate is 100 per tick, and if 3 machines tries to do so, they could only if the segment contain at leat 300 fluid.

Not sure which is the simplest/ most plausible explanation then x)

When a machine is updated, its max pulling rate is limited based on the filled ratio of the connected segment.

That would still hold be true, but i would see it as sparing some details for a further FFF

[Theikkru]

Yes, that would have been the idea, junction or not actually, just a single strech of pipe with 2 consumer connected on the last one would have given them both half the max potential pulling rate compared to having them offset by 1 pipe so they do not attempt to pull from the same, and so no matter the length of the pipe.

That would conflict directly with the statement:

[...]junctions are entirely unimportant[...]

---

It could be a symbolic quantity of fluid that can be transfered to every entity pulling from that pipe ,and next tick is removed for the quantity of the whole segment several time if needed. That would need to not exceed the total quantity of fluid in the whole segment to not "generate fluid". If a pipe can hold 100 fluid, max pulling rate is 100 per tick, and if 3 machines tries to do so, they could only if the segment contain at leat 300 fluid.
[...]

That would imply that there is a global limit on how much any one machine could draw from any pipe segment based on whether it's connected to a tank or a pipe, in addition to the nominal flow rating each machine already possesses in its properties. I see nothing in the FFF to suggest that, only the explicit special case for a tank-pump connection, specifically.
Furthermore, that method would incur a lot of unnecessary computational burden for the client, which, otherwise, would only need to perform a single calculation to look at the sum of the nominal flow rates of all (output) machines connected to a segment, multiply by the fill ratio of the segment, compare to the total fluid volume available in the segment, and then declare a global outflow multiplier for all those machines for that tick.
I'm afraid that the more I hear about that theory, the less likely it seems, given what's in the FFF, and the streamlining the devs are trying to accomplish.

[mmmPI]

That would conflict directly with the statement:

[...]junctions are entirely unimportant[...]

Hmmm not necessarily as junction could be describing for example a cross made of pipes without any pumps. When pumps are used it would not be a junction inside a fluid segment, it's another segment, so other rules applies.

There is a special case where a system to prevent fluid from being taken multiple times is needed when a single pipe has more than 1 pump pulling from it and i proposed a solution.

That would imply that there is a global limit on how much any one machine could draw from any pipe segment based on whether it's connected to a tank or a pipe, in addition to the nominal flow rating each machine already possesses in its properties. I see nothing in the FFF to suggest that, only the explicit special case for a tank-pump connection, specifically.
Furthermore, that method would incur a lot of unnecessary computational burden for the client, which, otherwise, would only need to perform a single calculation to look at the sum of the nominal flow rates of all (output) machines connected to a segment, multiply by the fill ratio of the segment, compare to the total fluid volume available in the segment, and then declare a global outflow multiplier for all those machines for that tick.
I'm afraid that the more I hear about that theory, the less likely it seems, given what's in the FFF, and the streamlining the devs are trying to accomplish.

Yes, that seem like the stuff i proposed is not very good x) but i'm not a game-dev, and i haven't spent lots of time on it, something better can probably be done and if it was what was prepared for the fluid 2.0 but not explained with enough details for me to understand i wouldn't be surprised ( not having everything mentionned explictly).

I mean, this discussion is super long and i'm still not sure i understand, so just from FFF it would have been impossible and maybe it was not attempted to go into those details, but rather let players know that something was done for the fluid, to gauge beforehand if it would be worth to do another FFF on that, or too risky or something and some more technical explanations not added for clarity.

[Theikkru]

[...]
There is a special case where a system to prevent fluid from being taken multiple times is needed when a single pipe has more than 1 pump pulling from it and i proposed a solution.
[...]

I don't understand what you mean by this; the rules as defined in the FFF should handle such a case normally. Lets say, hypothetically, that you have a pipe segment that is 2 pipe pieces long, and 3 pumps are trying to draw from one end of that pipe segment. Lets also assume that that pipe segment is half-full, and that all capacity and flow ratings are the same as current Factorio. The tick calculation would go something like this:
START
Get segment capacity - 200
Get segment fill - 50%
Determine segment volume - 200×50%=100
Sum output flow ratings - 200×3=600
Determine intended output - 600×50%=300
Check intended output against volume - 300>100→100
Determine output factor from intended output - 100÷600=16.6667%
Remove intended output from segment - [new segment fill 0%, 0 volume]
Determine pump output - 16.6667%×200=33.3333
Send output to pumps - [each pump gets 33]
Dump remainder - [one pump gets an additional 1]
END
It shouldn't matter how big or small the segment is, or how many machines are connected; the same calculation can service them all at once.

[mmmPI]

It shouldn't matter how big or small the segment is, or how many machines are connected; the same calculation can service them all at once.

In this example the segment capacity is 200, this is "too small" to illustrate what i mean, apart from being that "special case" as mentionned for me ealier, because in this case the whole segment even if filled at 100% cannot hold enough fluid for all 3 pumps to pull at the max rate.

Using the same value such as "segment capacity" , "segment fill" and the "check intented output against volume" but a bit different, i think it is possible to do first :

(1) read segment volume = amount of fluid in it
(2) get segment capacity ( number of pipe * pipe capacity ) +( number of tank * tank capacity ) ....
(3) get segment fill % ( (2) / (1) )*100
(4) get entity from which pumps are attempting to pull volume (3) * capacity of that particular entity
(5) get pump max optimistic pulling rate from that entity ( number of pump attached to that single pipe * (4))
(6) check if all pump can pull at max rate : => compare (5) and (1)
if (5) < (1) , all pumps gets to pull (4) quantity of fluid,
if (5)> (1), all pumps gets to pull [(1)/number of pumps]*(3) quantity of fluid

I called this a special case when (5)>(1) considering then pump cannot pull at the optimistic max rate, because there isn't enough fluid in the segment for that. So in such case they would pull at a lower rate than the "max rate", based on the fill level.

I think it's almost like you said, but somehow making a room for saying why 6000 fluid per secong could be the max pulling rate for a pump, based on the capacity of a single pipe being 100. And also why pulling from tanks is much better than pulling from single pipe ( 25000/tick vs 100/tick without any tweakings ).

I'm not saying it's likely or desirable, it's part of the stuff that i'm wondering.