Friday Facts #416 - Fluids 2.0

[Bowiemtl]

I much rather prefer the system to be fun but I will say that I'm gonna miss the flow direction animation. It looked nice but is tied in with the previous algorithm from my understanding

[Nemoricus]

I much rather prefer the system to be fun but I will say that I'm gonna miss the flow direction animation. It looked nice but is tied in with the previous algorithm from my understanding

Losing flow, seeing pipes fill up in sequence, and machines turn on one by one are all aspects I will miss, but I will miss the arcana of the current fluid system much less.

[adam_bise]

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

I suspect this as well. I think this change is a baseline which will be expanded on later.

[takisama]

I'm new to this kind of topic. Is this implemented in game or it's just a topic for talking about?

[Nemoricus]

I'm new to this kind of topic. Is this implemented in game or it's just a topic for talking about?

It’s implemented and being tweaked.

[takisama]

I'm new to this kind of topic. Is this implemented in game or it's just a topic for talking about?

It’s implemented and being tweaked.

Thanks mate. I'm a bit lazy reading patch note. Do you know what version did this change applied? Thannk you!

[Loewchen]

I'm a bit lazy reading patch note. Do you know what version did this change applied? Thannk you!

It will be in 2.0 expected to be released in October.

[Panzerknacker]

Isn't the old System basically letting each individual pipe spread its contents to adjacent pipes? That may seem "realistic" to most people at first, but it actually is just a simplistic/atomic algorithm that has a LOT of issues.

It requires forcefully moving fluids a random direction in order to drain a pipe for example. since when is a fluid puddle moving in an empty Pipe realistic?

There is so much jank required to make the "simplistic" or "atomic" old System work, that it rightfully turned out that a better and actually simple new System needed to replace it, to fix the glaring Issues.

If the Devs come up with an even betterer newerer System to replace this new "every section is ONE tank"-System, then wonderful, that would surely still take any type of lag and throughput Issues into account without trying to hammer in some bad design choices.

But the old System definitely needs to go the way of the Dodo.


to make it short

old System: broken, please delete, will not be missed, gimme back my lost lifetime and UPS!

new System: good, quite a few neat and consistent mechanics in there people didnt notice because of prejudicial "hurr durr, teleport no fun, trains dead somehow" without even thinking about some of the new emerging gameplay. You literally just need to place the Pumps at storage tanks and some junctions as opposed to inline everywhere.

If you put a fluid puddle in an empty pipe, it will spread in both directions (assuming that the pipe is level). That is exactly how the old system works.

old system = beautifully brilliant solution that gives a pretty good aproximation of fluid behaviour for a relatively very small computational cost.

[OnisDWA]

The old system was terrible, but the new one is not much better either.
I don't like that now liquid will be teleported in all cases, personally I don't understand what will happen in this case in case of liquid shortage, in what order will be given priority to consumers?
If in case of shortage all factories will receive the same amount of liquid, it's sad, because we will have to shut down extra factories, whereas in the old system the factories closest to the source would work, and we could not worry about it while expanding the production of liquids.

Based on the fff as I understand it, the 6000/s limit remains if the pump is going to be connected to the pipe, I don't see why...

As I see it the solution to fix the liquid teleportation could be fixed by using the old system, for cases where the pipe is filled to say <25%, so when some large section of pipe is connected the liquid would not be teleported instantly, but would flow in waves, which would bring back a realism. I assume that the wave would work like a pump (i.e. with a high flow rate), filling one pipe at the expense of the segment it is connected to, connecting it to the segment, and moving on to the next one.

[Sphinx]

I much rather prefer the system to be fun but I will say that I'm gonna miss the flow direction animation. It looked nice but is tied in with the previous algorithm from my understanding

It has already been confirmed here that there will be animations again. The ones from the FF are just placeholder graphics.

[GregoriusT]

If you put a fluid puddle in an empty pipe, it will spread in both directions (assuming that the pipe is level). That is exactly how the old system works.

old system = beautifully brilliant solution that gives a pretty good approximation of fluid behaviour for a relatively very small computational cost.

First of all, ever heard of surface tension and friction? Fluids will very much stop and sit in a perfectly level pipe. This sort of thing is usually not viable for gameplay reasons.

Secondly, the old system is just a slightly optimized version of the most atomically simplistic algorithm possible, which scales on a per pipe entity basis, so more pipes = more lag.

Thirdly the new System merges all those Pipe Entities into one Segment for processing, saving dozens of times the lag the Fluid System generated previously, and boy did it frikkin lag before in kilobases. It really disincentivized using Fluid Pipes for anything.

And lastly, as someone mentioned before, in real life a pipeline does NOT behave like an aqueduct, these things are filled once and then whenever you pressurize on one side, nets you in pressure on the other side. The pressure is being delayed yes, but the transfer of fluid is still instant like a real life water faucet/tap. So that aspect is actually quite realistic as long as the pipe is filled.

[huwp]

Suggestion:

When input flow increases, wait for a small amount of time: a constant * number of pipes to the segment. Yes it would mean closer consumers have to wait equally long as those far away, but I bet it'd feel natural. (And player can fine control with pumps)

[Walkop]

My issue with this system is this: why would you ever use trains to move fluids, now? It kinda takes away a large section of gameplay. Is there a way to create a max segment "length", and if that length is exceeded, max thoroughput is reduced? That way if you create a massive length of pipe, it requires a number of booster pumps to keep it moving, OR you build a rail system to move huge amounts of fluid without making a power network and booster pumps.

This is critical IMO, it completely invalidates fluid carts on trains as it stands.

[FasterJump]

And lastly, as someone mentioned before, in real life a pipeline does NOT behave like an aqueduct, these things are filled once and then whenever you pressurize on one side, nets you in pressure on the other side.

That's convincing.

However in the new system, a single pipe can supply a whole base, which removes the logistic challenge. I still believe that a proper solution exists.

[Necandum]

It is quite easy to just completely break the system (try connect 30 steam turbines in a row. The first 20 have availability, and the last 5. 5 are just...skipped. This is understandable given the algorithm, but completely broken from a realism and gameplay point of view).

35 steam turbines in one row behind 20 heat exchangers (2 rows of 10 exchangers, with some intelligent pipe merging/splitting to handle the combined steam throughput of 2026/s) work perfectly, is tileable, and even completely without pumps. Full 200 MW.

That's actually about the limit you can go comfortably. Water supply is the bottleneck here, in terms of space. The 2.0 system is for the case you want to go beyond that, with more and bigger and faster, and still be comfortable.

Screenshot 2024-06-24 180912.png

0eNq9m+9u4jgUxd8ln2EU/7l2zKusqipQl0ZqA0rCznSrvvs6MJ2mMzb3HlbafoOEnw/uubZjH96q7fMpHoeun6rNW9XtDv1Ybf56q8Zu37fP83vT6zFWm6qb4ku1qvr2ZX41TrF9WU+nYdv1sXpfVV3/EH9UG/V+t6piP3VTFy+g84vX+/70so1DuuEX4im20zq1G4fHdhcT+ngY08cO/dzojNLaf6NV9Vpt1tbX3yi1kjQc49CmdhNB1XW9ql4ODzMtsZ5jO05Jyx9t6q9tHrtjvrnwtbkMyQhJDUuyMpJRLImEpJolOSHJsCQvJGmW1AhJxJKCkGRZkqqFKM+jlBDleJTQ5oa3uRL63PA+V0KjW97oSuh0yztdCa1ueasrodct73UlNLvlza6Ebre827XQ7ZZ3uxa63fJu10K3W97tWuh2y7tdC91OvNu10O3Eu10L3U6827XQ7cS7XQvdTrzbtdDtxLvdCN1OvEXNp9u7/rHr07XyiuGzeFw4L3U+PnI/xmnq+v043/sT971Nq6YZE4ddarTdx/PC6uvqiDJro5zK3wop/tg9tf3+wr+yRHIhiXzohri73GFzbAOwF4sBEdsibMLYhLAbjO0A9mJWFLE9wrYYu0HYHmMHgL0Y8CRsWyNsg7EVwnYYWxcetjJot5Dtz6PHAq5zcAPAGxRu5XAPKycADit3cngDK/cAHFbeyOEBVh4AOKqcajHc1KhyUgAcVi6vUKNg5QaAw8rlFWo0rJwAOKxcXqHGwMo9AIeVyyvUWFh5AOCocgdUKKHKHVChBCsHKhSeQx1QofAc6oAKhedQB1QoPIc6oELhOdQBFQrPoQ6oUHgOdUCFwnOol1eohedQrwA4rFxeoRaeQ70B4LByeYVaeA71BMBh5fIKtfAc6v2N2wkue47wWZKCU5uzwhwlsJTF6UiJ0tQ8RfEUdeOWSLZ/Gs1r0rwmw1MMT7E8xfIUunFbJ98/jtdEvCbPUxxP4b28ODAqUsKNW1PZ/gkCTzespqB4Cl+lgfey5as0mBu31/L9w3va8jUfiKfwVRp4L1u+SsOtW4T5/uE9bfn6Cvz4bPmRQ9W8ma0TYNSNG50ujxPY2gtU8WO0bQSYr4ZeT4f1fjic+gfm7OzPyd9l8XTjRm6h73jLkxJ8aX78plqA4c1OWoAJN25I5/tI8a4nflhQih/DiQQY3u0kKGVlbtxYL/QRP4yTYGRQ/DhOglJWDqhBCuACXCmB25fr7pJKgdsbASZAmFKfad7lTlDCWkGY0pf6PXwgTbE5+x9SbGqRU4DOk+l/PU9W0gzE8rnVljqa4OhemeXgoFyZ5eH4XpnVwGG5MivAEb4iS5qEWD7UFVkKjvGVWRqOzJVZBk7ylVkWDs2VWQRn+cosB8fmyiwPp/nKrAYOzpVZAc7zFVm2hqNzZZaCE31llobDc2WWgTN9ZZaF43NlFsGpvjLLwQG6MsvDub4yq4EjdGVWgJN9RRbVcIiuzFJwtq/M0nAir8xanAictuPUngm56Ij9QKU1dtXHbv+0PZyG+ScNiuxdlm2F7Hmjq8g2K0WU55OMb+YnwrL2xHd5vhPy5wVLkU+J7/N8L+TPhVvku8Rv8vxGyHfX/rd+pVyd53/WWnxOT2BDt1vHPg7716vrfzOfQn02t9xBmW/+Hof743B4OP18s/548zReluH1r79VtT09PqZLY/fP1yvZhHst7I7mmh2b1B0q2x3Lg/trfFtfsWMSqZzO87WQr67YMYlUzuT5wqHAmit2nLXfrS6/jdosfkq1qv6Ow3h5Rm/S7BG0b1yoTW3f3/8FmFi5lw==

Copy blueprint

Complete tileable reactor setup:
Screenshot 2024-06-24 181515.png

Sorry, I mispoke! I meant heat exchangers, the ones used in nuclear to turn heat into steam (I'm bad with names). The numbers are approximate as I don't remember the exact figures from awhile ago.
Edited original post.

And yes, I'm aware you're not meant to stick 30 of them end to end. I was just messing around in sandbox trying to find the limits of the system to understand it better. I cheated in the heat btw, using one editor only heat pipe per heat exchanger to guarantee max steam production, and had an editor entity per exchanger to void the steam.

Thanks for posting a correction!

[functional]

However in the new system, a single pipe can supply a whole base, which removes the logistic challenge. I still believe that a proper solution exists.

It actually doesn't. Routing those pipes is far more annoying in my opinion than solving the problem with trains to begin with. You may disagree on that, and that's fine - but you can't pretend that there's no logistic challenge in trying to route pipes everywhere.

In classical bus base designs, you would typically have a single pipe anyway in status quo. In anything scaled up from that, you would most likely use trains because they specifically solve that whole logistic challenge. Plop down some rails and now you can transfer fluid or items from anywhere to anywhere in the network (assuming its designed that way, like I always do personally). I can't see why I would run 8 pipes (water included) everywhere, even when that no longer requires pumps. It's actually interesting to use the "removes the logistic challenge" argument, because same argument can be just said for trains; with trains you can trivialize your whole production completely by turning it into a set of inputs and outputs without having to worry too much about belts crossing each other etc.

Also, to be quite frank, there is no real "challenge" to begin with. The old system simply had hard limits to it and you could not really solve those (thus not being challenges to begin with), there were just massive design constraints where you had to place million pumps. There's nothing you can do about the 4,8k flow being the max flow (pipe to pump to pipe) and if you wanted more flow, you just had to have more parallel pipes. This isn't a challenge, just repetitive actions. And also some jank was necessary too because you needed a pump after every pipe in your main line.

EDIT: Proper solution may exist, but you have to understand some realities here: currently there's only two to three unique solution (depending on how you count em) and this is how it has been for ages now. First is simply to change nothing. Second is scaling up (which solves very little ultimately) and third is the "electric network" solution which this is a variation of. Stuff like Fluids Must Flow goes into the scaling up bin.

This isn't something they did after a short consideration. There have been proposals for ages for fluid change and clearly devs understood all this time that the fluid system kinda is the least enjoyable part of factorio for most people.

[FuryoftheStars]

There's nothing you can do about the 4,8k flow being the max flow (pipe to pump to pipe) and if you wanted more flow, you just had to have more parallel pipes. This isn't a challenge, just repetitive actions. And also some jank was necessary too because you needed a pump after every pipe in your main line.

I'm curious, how is the fact that pipes can only transfer so much per second any different from belts? And really, should this not be expected? I mean, the pipes do have a finite diameter.

Yes, the rate of flow drop off probably occurred too quickly causing the "need" to use pumps so frequently. Though I think that's more a balance discussion?

[functional]

There's nothing you can do about the 4,8k flow being the max flow (pipe to pump to pipe) and if you wanted more flow, you just had to have more parallel pipes. This isn't a challenge, just repetitive actions. And also some jank was necessary too because you needed a pump after every pipe in your main line.

I'm curious, how is the fact that pipes can only transfer so much per second any different from belts? And really, should this not be expected? I mean, the pipes do have a finite diameter.

Yes, the rate of flow drop off probably occurred too quickly causing the "need" to use pumps so frequently. Though I think that's more a balance discussion?

- Belts do not require (or even have) pumps, as their throughput is (mostly) a constant.
- Their behavior is uniform; a straight line of belts performs exactly as well as a straight line of underground belts.
- Belts also do not require power (unlike pumps)

Lot of differences emerge specifically from pumps. Here is an example of what is required to do a tiny S-bend without losing any of the max throughput:



5 pumps at minimum, possibly 6 if you need to do it on the other side. (Or replace it with underground pipe, I rarely do because I just have the pump on hand anyway...)

Belts also do not merge with one another in unwanted ways (they can, just not like pumps). You can easily run 8 parallel belts in 8-width, but for 8 different pipes youd need 14-width.

Also, to be quite straight with you, I think these differences are painfully obvious...

And its not a balance discussion. Either the pumps are required or they aren't. If they are required, scaling them up does not actually remove the problem.

[Henry Loenwind]

Have you considered copying Ender IO Fluid Conduits instead? The basic ones could provide a nice middle ground:

When something pushes into a conduit, it first fills up that conduit's local buffer. If that buffer is full, it fills up the next conduit's buffer and so on. When that encounters an exit connection, it directly pushes there. At the end of the tick, i.e. after all inputs have pushed, the conduits try to first push into outputs (if those have capacity left that tick) and then equalise with their neighbours. The rate limiting is done by tracking all input and output connections and limiting the amount that goes in/out per tick.

The advantage is that a partially filled line will flow and slosh, but a fully filled pipe will have full throughput as if the input and output were connected directly. Also, for pushing into the network, it doesn't matter how full the directly connected conduit (pipe segment) is, as its content will be pushed along the pipe, in a way.

However, this would change the semantics of buffer tanks. With them being treated as big pipe segments, they would reduce the efficiency of the segment (unless they are full). One way to counter this would be to also copy the Capacitor Bank logic. Those act as low-priority targets for non-capacitor sources during the input phase, then try to push out before the conduits try to do so. That way they keep the network filled while taking in any excess.

[SirSmuggler]

I think it looks silly to sorund a machine with beacons.
I think its horendus to let inserters grab from the back side of underground belts (or from underground belts at all actualy).

The list can go on. There is however a very simple solution to all my gripes, and it's not yell at the devs and try to force my way of playing on others, its simply to not build my factory in that way.

So my suggestion for thouse who think this change will invalidate trains or that a single pipe supplying infinite througput is silly, is to simply not build in that way just because it is possible.

If you like trains, use them, no one is stopping you. If you think your nuclear plant looks better with a bunch of parallel pipes and some extra pumps, then build it that way, it will still work fine.