Factorio Forums

TL;DR

To make fluid flow to behave exactly the same way for rotated / flipped layouts

What ?

Now (ver 1.1.32) fluid flow is highly dependent on the direction of the pipes. For example, here is totally symmetric layout (inner infinity pipes have 100% of water, outer infinity pipes have 0% of water), which was left for more than 1 hour to run (to exclude initial irregularities). Regular pipes in corners contain amounts as shown: I would expect to see something like that:

Why ?

To make fluid dynamics more logical and easier to understand, to make designs scalable, to reduce ugly bulky "fixes" for complex designs with heavy fluid load (like large nuclear plants), to reduce frustration among players (when rotation / flip of a perfectly working layout can shrink or even break it's capability) etc.

How ? (boring tech suggestions)

I guess that flow is dependent on the direction because of iterative changing of live pipe contains from tick to tick. But one can keep in memory two copies of pipe contains - a "live" one and a "next tick" one. A "next" copy can be calculated using "live" copy data (totally ignoring "next" copy data and just rewriting it). And after that references to these copies can be switched, so the fresh "next" one will be a new "live".

Pros:
- that can be done in any order / in parallel, easier to maintain, better user experience
- result is much more clear, predictable and testable
Cons:
- adds negligible cpu load (3 assignments per tick for the reference switch)
- adds memory load (depends on current implementation, can't estimate)

Potential

Adds the ability to calculate an actual "flow" and use it for more close-to-the-real-world dynamics later, or at least introduce "really not peaceful" mode for hardcore players with a fluid hammer effect, which can damage or ruin random parts of a fluid system in case of a biter attack.

I think you have no idea of how pain in the somewhere fluids implementation is to maintain, or even change to something better while not causing huge performance penalties.

For the fluids flow to be "fair" it would have to be a 2-pass algorithm because it would have to first compute all the fluid flow values in a way that does not violate the fluid volume constraints, and then they would have to be applied onto the pipes. Right now it is a single pass algoritms and even now it needs to be multithreaded to not cause some severe performance issues when there is a lot of pipes in game.

All the behaviors players complain about are because of the single pass approach fluids are doing which has 2 consequences: 1/ order of updates matters and it may be weird - connection update is performed by the fluidbox with lower position (lower y; if y is same: lower x) and fluidboxes are updated in some weird order sometimes dictated by entity building order, sometimes not; 2/ flow along one connection may cause other connection out of the same fluidbox to have lower flow because it sees lower value of the fluid volume.

If the 2-pass approach would be implemented, it would either have to use only some fraction of the fluidbox volume to decide amount of transfer (which would immediately reduce all the flow values with pipes), or it would have to be even more passes or more complex approach that would visit all the neighbour fluidboxes to decide in which direction fluids will flow along which connections to decide the fractions for the flow values.

Having more passes and touching more fluidboxes (not only along the "update" connections) would cause reduced performance so there would be a lot more changes needed for such ideas to work nicely.

Oh, I can feel that omnidirectional stream of suffering

Is there any more information about "what goals current implementation is designed to achieve"? Like "that much flow for pipelines of that length" or something like that (in addition to the numbers on wiki pages). If it's not too much trouble, of course

I would like to create / test / compare some mocks of a fluid system - to share with you guys the least terrible results and implementations
This way to resolve my struggle with nuclear plant design may be too much, but it's definitely more fun

Isn't this viewtopic.php?f=5&t=95010 again?

In principle yes, but that discussion is in general, this is a suggestion. Not merged, but thanks for linking.

[Koub] Implemented in 2.0 yay \o/ :
https://factorio.com/blog/post/fff-416