Friday Facts #416 - Fluids 2.0

[Loewchen]

I haven't read all the 19 pages. Did anyone suggested to limit the total push rate to 12000? Should be super easy to implement.
This will not solve the issue completely, but at least there will be no "a single pipeline is enough for entire megabase".

That limit could only be per pushing entity, so if 12k or infinite is pretty irrelevant. The "pipeline throughput" as in, the inter segmental transfer does not exist so can not be limited what so ever. To make it clear once more, there is no concept of fluid transfer inside of segments anymore.

[MeduSalem]

I haven't read all the 19 pages. Did anyone suggested to limit the total push rate to 12000? Should be super easy to implement.
This will not solve the issue completely, but at least there will be no "a single pipeline is enough for entire megabase".

That limit would could only be per pushing entity, so if 12k or infinite is pretty irrelevant. The "pipeline throughput" as in, the inter segmental transfer does not exist so can not be limited what so ever. To make it clear once more, there is no concept of fluid transfer inside of segments anymore.

It is not irrelevant. ^^

Because they could limit the push-rate per entity proportional to the amount of entities that want to push into the pipesegment.

If the total limit is 12k then you could for example have 1 entity that ouputs 12k fluid per second or 12k entities that output only 1 fluid per second each.

And that is how I would force a throughput limit onto a pipe segment.


But that is what I already suggested in mmmPi's thread 2 weeks ago.

[Loewchen]

Because they could limit the push-rate per entity proportional to the amount of entities that want to push into the pipesegment.

If the total limit is 12k then you could for example have 1 entity that ouputs 12k fluid per second or 12k entities that output only 1 fluid per second each.

How could this ever be acceptable gameplay wise? You have a pump that pumps from a full tank into an empty tank, but the transfer is almost zero because that tank is part of a segment with hundreds of other pushing machines hundreds of chunks away and there is an "absolute push limit".

[MeduSalem]

Because they could limit the push-rate per entity proportional to the amount of entities that want to push into the pipesegment.

If the total limit is 12k then you could for example have 1 entity that ouputs 12k fluid per second or 12k entities that output only 1 fluid per second each.

How could this ever be acceptable gameplay wise? You have a full pump that pumps from a full tank into an empty tank, but the transfer is almost zero because that tank is part of a segment with hundreds of other pushing machines hundreds of chunks away and there is an "absolute push limit".

That is the fun part of doing it proportionally.

In above case I assumed all 12k entities have the same "push rate". But different machines/entities usually don't have equal pushrates. Machines usually have much less than a pump.

For example a generic chemical plant might only want to push 100 fluid/sec into the pipesegment. But the pump wants for example to push 12000/sec into it.
With a total limit of 12k the chemplant would get about 99.17/sec and the pump would get about 11900.83/sec.
Because of how proportions work the pump would have about 119 times the priority over the chemplant.

Sure if you have 120 chemplants then they would be together as strong as the pump. Then the 120 chemplants would push 6000/sec into it and the pump would also push 6000/sec into it. But nothing prevents you from putting another couple pumps there. xD

[Loewchen]

Because they could limit the push-rate per entity proportional to the amount of entities that want to push into the pipesegment.

If the total limit is 12k then you could for example have 1 entity that ouputs 12k fluid per second or 12k entities that output only 1 fluid per second each.

How could this ever be acceptable gameplay wise? You have a full pump that pumps from a full tank into an empty tank, but the transfer is almost zero because that tank is part of a segment with hundreds of other pushing machines hundreds of chunks away and there is an "absolute push limit".

That is the fun part of doing it proportionally.

For example a generic chemical plant might only want to push 100 fluid/sec into the pipesegment. But the pump wants for example to push 12000/sec into it.

Because of how proportions work the pump would have 120 times the priority over the chemplant.
Sure if you have 120 chemplants then they would be together as strong as the pump. But nothing prevents you from putting another couple pumps there. xD

Again, how could this ever be acceptable gameplay wise that a pump does not pump from a full fluid box into a empty fluid box just because enough other pumps pump into the segment hundreds of chunks away? It's completely unexpected by any player not familiar with this arbitrary and nonsensical limitation.

The one thing the new "fluids" have going for them is, that they produce predictable results. Pull power is only limited by fluid level, push power is not limited, fluid levels only exist per segment. The new system is honest in regards in that it is now a game mechanic and not a fluid simulation, shoehorning in an absolute throughput limit is not.

[coppercoil]

Again, how could this ever be acceptable gameplay wise that a pump does not pump from a full fluid box into a empty fluid box just because enough other pumps pump into the segment hundreds of chunks away?

This is how multiple pumps work in a real word (if we had no sound speed limit, like in 2.0).

[MeduSalem]

Again, how could this ever be acceptable gameplay wise that a pump does not pump from a full fluid box into a empty fluid box just because enough other pumps pump into the segment hundreds of chunks away? It's completely unexpected by any player not familiar with this arbitrary and nonsensical limitation.

The one thing the new "fluids" have going for them is, that they produce predictable results. Pull power is only limited by fluid level, push power is not limited, fluid levels only exist per segment. The new system is honest in regards in that it is now a game mechanic and not a fluid simulation, shoehorning in an absolute throughput limit is not.

It sounds like you don't understand how proportions work, and I kinda refuse to believe that. ^^

If you use a proportional system it will ALWAYS take some fluid also from the pump right next to the full box. It might not take it at full speed, true that, it would depend on how many other entities are trying to push into the pipe-segment, but it will never be none unless the fluid-segment is already completely full itself, but then... you cannot expect it to push more into it.


Also not like you cannot put some information when highlighting a pipesegment. You could totally write a number there that says how much of the throughput limit you are already using in % or as a number like 6000 of 12000 or whatever. That would give the player enough hint how many more entities they might still hook up to the segment.


Anyway for me it is acceptable.

And also I don't have a problem with there not being a throughput limit at all. I don't really care whether there is, or there is not.

I only suggested the easiest method to force a throughput limit with the new fluid system. ^^

[coppercoil]

There may be a misunderstanding if we think differently about how the liquid flows: open channel flow (aqueduct) or closed channel flow (pressurised pipe). In a closed pipe the pressure distribution is limited by the speed sound in a liquid. If there's no sound speed limit, all pumps work like they all are placed near each other.

[Panzerknacker]

Anyway for me it is acceptable.

I thought the whole point of the new fluid mechanic was to remove some quirks from the current simulation system that made it too hard for certain players. If the new system will also have different quirks what is the point?

And no, it's not UPS because 90% of the playerbase does not build large enough that they will run into that. I wouldn't even care to build big in the first place if the game was not fun (it's fun now with the current fluid system!)

[Loewchen]

There may be a misunderstanding if we think differently about how the liquid flows: open channel flow (aqueduct) or closed channel flow (pressurised pipe). In a closed pipe the pressure distribution is limited by the speed sound in a liquid. If there's no sound speed limit, all pumps work like they all are placed near each other.

None of that is relevant.
The pressure/level on the low side side is maxed, the pressure/level on the high side side is zero. If the answer to "What is the pumps fluid transfer compared to its maximum rate?" is anything other than "100%" its wrong, and if it is "some fixed absolute value/(number of all pumps pumping into the segment)" it is nonsense.

[bobucles]

That is the fun part of doing it proportionally.

Nah, not a fan of doing proportional flow. Fractions and division are hard calculations and need to be done every time. Pipes don't need to get better with size, if anything they should be getting worse.

The simplest system (probably) is to throttle the total input in the pipe segment. Once the pipe has full input, there is no way to get more output out of the pipe. Flow rate can be adjusted with a simple look up table, bigger pipes have less total input capacity and thus less total flow rate. It also only needs to be recalculated when the pipe network changes, which is a very uncommon event. Give storage tanks their own extreme input rate and pumps split up networks, and everything is peachy.

[kitters]

Too bad there is no like/dislike system in this forum, and one can not simply express that they agree/disagree other than type another post.
By the way, I found suggested by MeduSalem system absurd, and agree with every word of Loewchen.
Especially:

The pressure/level on the low side side is maxed, the pressure/level on the high side side is zero. If the answer to "What is the pumps fluid transfer compared to its maximum rate?" is anything other than "100%" its wrong, and if it is "some fixed absolute value/(number of all pumps pumping into the segment)" it is nonsense.

[Loewchen]

Too bad there is no like/dislike system in this forum, and one can not simply express that they agree/disagree other than type another post.
By the way, I found suggested by MeduSalem system absurd, and agree with every word of Loewchen.
Especially:

The pressure/level on the low side side is maxed, the pressure/level on the high side side is zero. If the answer to "What is the pumps fluid transfer compared to its maximum rate?" is anything other than "100%" its wrong, and if it is "some fixed absolute value/(number of all pumps pumping into the segment)" it is nonsense.

The thing is, the idea is so obviously bizarre to me that I still think I must be misunderstanding it somehow, but the more I think about it the worse it gets.

[coppercoil]

If the answer to "What is the pumps fluid transfer compared to its maximum rate?" is anything other than "100%" its wrong, and if it is "some fixed absolute value/(number of all pumps pumping into the segment)" it is nonsense.

Serving entire megabase with a single pipeline is nonsense too. So actually now we are discussing which nonsense gives better gameplay.

[Loewchen]

Serving entire megabase with a single pipeline is nonsense too.

It is an extreme simplification, but in context of the the now extremely simplified system as a whole it is coherent and not unexpected.

So actually now we are discussing which nonsense gives better gameplay.

Kinda. We discuss the quality of a gameplay mechanic based on how it produces results that can be predicted and expected instead of comparing it to a simulation it no longer tries to be.
To tune down the simplification one could just change the throughput of pumps from input level * pump maximum to (input level²/output level) * pump maximum. It would better meet the expectation that pumping against higher pressure reduces throughput without introducing completely unexpected absolute segment limits. But since they did not do that they must have wanted it to be that simple.

[raiguard]

I have read every single reply on this topic, and I am taking your feedback seriously. However, any solution that involves fluid physics and/or splitting segments at junctions is not going to happen. There are too many architectural changes that I would have to undo to reintroduce physics.

The problem with the old system wasn't that it had limits, but that the limits were completely nonsensical and not communicable to the user. The new system can be adapted to have some limits as long as they are clearly communicated and consistent. I am working on some ideas for how to do this.

[Panzerknacker]

Cool a reply from the dev! Don't expect you to enter a discussion here but I would like to ask why it is a problem that the limits are not clear? I think it's fun to make builds by experimenting instead of being able to plan everything ahead exactly like with many other systems in the game. I also think that by using the pipes often in big builds you will adapt a feeling for how they work.

[mmmPI]

The new system is honest in regards in that it is now a game mechanic and not a fluid simulation, shoehorning in an absolute throughput limit is not.

I learned a new word today ! ("shoehorning" i knew the others )
I think too that the new system is not a fluid simulation anymore but a game mechanic, and it is honest.

For the second part i think one can question "absolute", with "arbitrary". From reading the FFF and the following discusions about it, it seems like some "arbitrary" value will be choosen. In that there will be numbers to tweak in some formulas. It may be seen as some sort of absolute limit afterward. The "arbitrary" numbers would be "how many ticks are needed for the fluid in the video show in the FFF to fully be into the last tank of the snake pipe" vs "in the not snake pipe". It would be more complicated than that of course, but how much more complicated is still not fully understood for me , i suppose that's part of the fun of playing with the new system

It is visible on the last video that the "short straight" pipes and the "long snake" yield different time , so there will be some throughput limits induced by pumps which are entities that "cut" fluid segment into different ones. And the "length" or "volume" of that segment seem to impact the throughput.

In a way it seem to me like the throughput of the pump is also the througput of the segment, and thus the maximum for a pump, would be with the shortest segment. The scaling i suppose is "arbitrary" and thus yield "absolute limits" somehow, for it to be predictible it has to be linear no ? if a segment is twice as long, it should take twice as much time ?

The value at 0 and the value at 1 are sort of arbitrary then and are "absolute limit".

Maybe that sort of reasonning doesn't apply here , and i am misunderstanding severals things but i think it is somewhat confirmed by raiguard that wrote this message while i was trying to organize my thoughts for this one

Cool a reply from the dev! Don't expect you to enter a discussion here

Hey that's not fair, it's not the first time Raiguard comes to try and clarify things and this time on a saturday !

[kitters]

I have read every single reply on this topic, and I am taking your feedback seriously.

THANK YOU!

However, any solution that involves fluid physics and/or splitting segments at junctions is not going to happen. There are too many architectural changes that I would have to undo to reintroduce physics.

By physics you do mean simulations of fluid units movement, I believe... To roll back changes seems for me to not take too much efforts. And generally speaking rolling back sometimes may be a right decision to make. In our case... If you find another solution for the problems (increase throughput, ...), would you consider roll back to the simulation and implement different change? Or is there some ideological reasons for new fluid mechanic?

[Panzerknacker]

This is probably a ridiculous idea but couldn't it be possible to optionally hardware-accelerate fluid calculations by offloading it to the GPU? Like neural network should be able to perform that? Then have all the data ready in memory for when the next game update is gonna be done by the CPU. Like, the CPU calculates the segments where fluid is drawn from a pipe segment into a machine and the GPU handles evening out the segments in the pipe. But yeah, probably complicated like multithreading.