Optimize Fluid calculations

[MagicKyrano]

Summary

Optimize Fluid calculations.

Additional resource links

[0.15.x] Fluid mechanics: viewtopic.php?t=19851 (explanation of Fluid mechanics)

Explanation

If you have a lot of pipes / pumps / storage tanks, the way fluids work (as explained in the link above to [0.15.x] Fluid mechanics) makes that there are a lot of calculations to be done.

If the calculations in the accompanied link are correct, calculations are done between each pipe and their neighbours.

Request / Proposal

If you have a number of same pipes connected to each other, treat them as one whole item. That way, any calculations on that collection of pipes has to be done only once per tick, instead of once per tick per item.

I propose to group the following items:

• All pipe segments that are connected to each other, until either a non-pipe is met, or pipes interconnect with other pipes (split off)

• All storage tanks that are connected directly to each other (no pipes in between)

And then when the fluid mechanic is calculated, only calculate it once per tick over those grouped items.

With Storage Tanks grouped, you basically have one big storage tank, where each tank receives a percentage of the total amount of storage that that grouped unit has. And the grouped pipes behave like they are a single pipe.

However, grouped items should still behave roughly the same as items ungrouped. Which means that the size of the grouped items, be it in total tile size (X x Y) or number of pipes used of the grouped item, should be taken into account. For example, a long grouped string of underground belts from one side of the camp to the other side, should be one grouped item but with lowered max pressure of something like that.

Advantages

Big groups of pipes or storage tanks only need to be calculated once per tick.

[Rseding91]

viewtopic.php?f=18&t=19851&start=40#p270273

[Engimage]

viewtopic.php?f=18&t=19851&start=40#p270273
...
Now, I don't know if that's going to happen - it has some drawbacks like not having a defined fluid flow direction but (to me) the benefits far outweigh the loses

Hopefully this is going to happen

[MagicKyrano]

As long as it doesn't change too much about the way the game works, and possible bugs are accounted for, this could speed up the game, and is the reason why I wrote the proposal. The hardest part, in my view, is making sure that the grouped entities behave roughly the same as the ungrouped entities. (In terms of speed, fluid lag, etc).

[bobingabout]

My only issue with the suggested new system, is that if all the pipes are just one merged set... how us flow calculated?
also what happens if you accidently connect two pipes that have different fluids in them together?

[Engimage]

Another issue I thought of is how to calculate throughput limits. You might make a 2 pipe wide connection now to allow more throughput but if it is considered a single block the limitation might not be calculated clearly especially if there are several providers/consumers on it.

[eradicator]

My only issue with the suggested new system, is that if all the pipes are just one merged set... how us flow calculated?

My guess is the behavior would be the same as if basically everything was connected to a single huge tank with an infinite number of input-output connections. So the flow limit would be purely a function of the fluidboxes in the machines that do the actual production/consumption of fluids. Thus the flow speed between any two connections of the "tank" would be infinite?

also what happens if you accidently connect two pipes that have different fluids in them together?

Sounded to me like that's just not going to be possible at all, as each "tank" can only have one fluid.

Except for the problem of "which direction does the flow animation go"? I'd love to see that implemented.

[MeduSalem]

My only issue with the suggested new system, is that if all the pipes are just one merged set... how us flow calculated?

Another issue I thought of is how to calculate throughput limits. You might make a 2 pipe wide connection now to allow more throughput but if it is considered a single block the limitation might not be calculated clearly especially if there are several providers/consumers on it.

I'd say flow in pipes could be infinite... there's not much fun to be had with limitations in pipes anyways because that's why the current pipe mechanic already sucks majorly.

Let the machines/pumps with their inputs/outputs determine the maximum flow. Pumps will bascially act as a gate between two pipe-sets anyways and it has a maximum input/output.

The pipe spaghetti in Oil Industry is already enough complexity anyways even without throughput problems which would only really be relevant to Nuclear Power or large Steam Plants where huge amounts of fluid are transfered every second.



But that said I have an idea on how it could be somewhat "faked":

There could be a throughput limit on each pipeset... like for example 1000 Units/second... and machines/pumps can't add/draw more than that per second to/from a pipeset. It could be displayed when hovering over a pipetile from a pipeset as <current throughput amount>/<throughput limit> or using graphical bars...

To increase that throughput limit you have to place pumps somewhere... each pump for example adding 500 Units/second to the 2 pipesets they are connected to. Maybe there could be a diminishing return or so, so eventually it would be better to have second, seperate pipeline that isn't connected. A pump would only be counted as a boost to the throughput limit if it has a fluid in the inputbox... to prevent people from using dummy pumps that don't do anything.

And since the pumps basically act like gates between two pipe sets you would still have to put multiple parallel pumps to increase the fluid throughput further. Serial placement of pumps would only allow for 2 pumps per pipeset (one in, one out).

So for example:

• Basic pipeset without pumps has a throughput limit of 1000 Units/Second
• Pipeset with 1 Pump has 1500 Units/Second
• Pipeset with 2 Serial/Parallel Pumps has 2000 Units/Second
• Pipeset with 3 Parallel Pumps has 2500 Units/Second
• ...and so forth.

Numbers are obviously up to the Devs to balance. They are just examples here.

Don't know if my idea is understandable though... xD

also what happens if you accidently connect two pipes that have different fluids in them together?

Either they aren't connectible as long as they aren't drained...

... or the pipeset with more total fluid pushes out the fluid of the other pipeset with less total fluid. Since both pipesets are internally handled like being just "one huge tank" all inputs/outputs are connected to that should be possible to do.

Except for the problem of "which direction does the flow animation go"? I'd love to see that implemented.

I would say for a complex solution the flow animation could be done via calculating a path/tree from inputs to outputs just for aesthetic purposes of determining the flow direction without actually being used for internal flow calculations. That path could be calculated once and is cached from then on until the pipenetwork gets updated with more inputs/outputs/pipes.



But what I'd prefer is... simply faking it... there are some optical illusion techniques where the animation makes it indistinguishable which direction something is seemingly moving. You'll surely have seen something like it in real life where something that is moving in one direction actually looks like it is moving the opposite direction. Here a youtube video of the effect I'm talking about:

https://www.youtube.com/watch?v=m6a2Qtu3728

That optical illusion could be abused as a cheap solution for the flow direction. Your mind thinks it should be moving in a particular direction and that's what your brain will make you see.

[eradicator]

Except for the problem of "which direction does the flow animation go"? I'd love to see that implemented.

But what I'd prefer is... simply faking it... there are some optical illusion techniques where the animation makes it indistinguishable which direction something is seemingly moving.

The point i was trying to make is that the animation direction can sometimes (admittedly rarely) be used as a diagnostic instrument to debug why something isn't working. The most common case would be if it's not moving at all though so that's at least easy to keep.

That optical illusion could be abused as a cheap solution for the flow direction. Your mind thinks it should be moving in a particular direction and that's what your brain will make you see.

That's a bad idea imho. Because new player don't expect it to go into any particular direction, and thus will see random confusing results. So i'd prefer an animation that either statically looks like it's flowing towards outputs (like the cached tree you suggested above) or to make the animation in a way that doesn't suggest either way. Any anyway now that i know it might be an illusion i'm not going to be able to forget about it. Curse you

[Engimage]

If pipe automatic interconnection is fixed allowing manual pipe connections and we assume that any pipe set has a certain maximum throughput of a single pipe - this is a working strategy.
If a player wants to combine several pipes for maximizing throughput he can do so by having 2 parallel pipes (instead of crossbread ones) which will look and feel much more convenient.
As to flow direction - I think you can freely drop it from animation cause it has no real benefit. The color of a liquid however makes much more sense. However the liquid flow animation makes some sense in terms of detecting if flow is happening at all and your system actually works. But I am sure you can come up with something to replace it.

[Koub]

[Koub] Implemented in 2.0, at least I guess :
https://factorio.com/blog/post/fff-416