Friday Facts #260 - New fluid system

[WilliamR]

Hey,

first of all, I didn't read the full article. (I'm supposed to work right now) However, I'm really interested in this topic and I have some input from the perspective of a audio developer. Basically, some thing I've noticed while studying audio stuff is that linear systems behave similar in electronics, fluid dynamics and in acoustics. its the same idea every time, be it voltage vs current or pressure vs velocity.

In digital audio, we have the issue of writing discrete systems that mimic the continuous real life system. One method for wave propagation is finite difference method which seems to be what your current state is. You have a fixed number of samples (pipes) and a fixed number of updates a second (tick rate) that you update every pipe using some formula based on neighbouring pipes.
Something that we use in my company more often is wave guides. For instance, a guitar string, once excited, will throw a wave in both directions of the string. The sum of those waves (or the difference, depending on some definitions) is then equal to the deflection of the string, or the velocity. The stuff we have to simulate is what happens to those waves when they meet a "change" in the medium. I.e, when the wave reaches the end of the string, it' can't continue like normal and has to reflect.

The idea is simply but it can be applied to basically everything. Pressure in a pipe or standing waves of water should be absolutely doable. The beauty is that you don't need to simulate what happens in the pipe (or across the string), at least not for linear systems. You only need to deal with what happens when the impedance changes. For instance, what happens to our waves when they meat in an intersection. What happens when they "see" a big tank, or a pump.

However, you guys have quite different requirements. The limited throughput for instance would probably mean a nonlinearity. In theory, you can always increase the pressure to put more stuff through a pipe. In reality, that's not really the case...

[steinio]

How about eliminating pipes completely and only offer barrels *duck and cover'

[Oktokolo]

first of all, I didn't read the full article.

No problem. Bringing in fresh ideas without contaminating his thoughts by reading about the requirements or previously discussed solutions first is the best method for participating in lengthy discussions anyway.

[Jap2.0]

*duck and cover'

At least you know to do that, maybe you should work on knowing not to suggest things that everyone will hate you for?

[mudcrabempire]

[deleted (duplicate from the next post)]

[mudcrabempire]

At the risk of repeating an already posted idea:

How about treating the fluid in pipes like items on transport belts?
-Stuff that produces fluids unloads it onto the "belt" (into the connected pipe segment).
-every pipe segment transfers it´s content to the next at a defined speed.
-junktions are treated like splitters.
-fluid tanks are treated like those chest things you place next to irregularly used belts: they fill up from the surplus in the pipes, and if the pipes are underfilled, they empty themselves to keep the pipes full.
-pumps can be used to make the flow in the next few pipe segments faster (think of upgrading the next few "belts" into faster "belts").

The main difficulties would be to "reserve" pipes for a certain fluid, so they don´t mix, and to tell the fluids in which direction to flow, since pipes work both ways, as opposed to transport belts.

That would obviously not be a lot like real-life pipes, but it could be a simple and not too calculation intensive solution (I think, haven´t checked).

[McDuff]

At the risk of repeating an already posted idea:

How about treating the fluid in pipes like items on transport belts?
-Stuff that produces fluids unloads it onto the "belt" (into the connected pipe segment).
-every pipe segment transfers it´s content to the next at a defined speed.
-junktions are treated like splitters.
-fluid tanks are treated like those chest things you place next to irregularly used belts: they fill up from the surplus in the pipes, and if the pipes are underfilled, they empty themselves to keep the pipes full.
-pumps can be used to make the flow in the next few pipe segments faster (think of upgrading the next few "belts" into faster "belts").

The main difficulties would be to "reserve" pipes for a certain fluid, so they don´t mix, and to tell the fluids in which direction to flow, since pipes work both ways, as opposed to transport belts.

That would obviously not be a lot like real-life pipes, but it could be a simple and not too calculation intensive solution (I think, haven´t checked).

The problem with this is that pipes can flow both ways while belts can only flow one way.

[McDuff]

Is there any chance of an update of how this is going in a new FF?

[Klonan]

Is there any chance of an update of how this is going in a new FF?

Yes, we will give an update soon

[sarcolopter]

sooo on average, how many pipes do you need per section for every junction in a system for it to run than faster the old system?

More than 2 + 2/x pipes, where x is the amount of pipes connected to the junction.

In the last example picture why can't some of the segments and junctions be merged further resulting in fewer entity updates? Consider a scenario where the segment on the left is attached to some fluid producer and the 5 segments on the right are each attached to a fluid consumer.

If A and B are each connected to a fluid consumer then junction 1 and segments A and B can be merged into 1 segment that has an input at junction 1 and where the output is split between A and B. The same can be done with segments D and E and junction 3 and from there you could possible merge the top and bottom segment with segment C and junction 2. You could even pre calculate the even distribution when merging these segments. When you merge A and B on junction 1 you know you need to split 1/2 to A and 1/2 to B. Then you do the same when you merge D and E on junction 3. Then when you merge segment C with the top and bottom segments you know that 1/3 would be distributed to each segment which means you can multiply the existing distributions by 1/3 giving you A) 1/6, B) 1/6, C) 1/3, D) 1/6, and E) 1/6.

That's basically the nuclear option they decided not to use.

About the pipe calculation.

Why don't you do the calculation per group instead of one calculation per piece of pipe?

Example,

To make thing simpler, let's say each pipe can hold a total number of 100 'unit' of water

Group A have 22 pipe total, 2200 unit total.

You fill the first pipe with 100 unit of water. The group A have 100/2200 unit with water. So each pipe need 1/2 unit each, in other words ~4.5/100 unit of water.

Of course, if you do that instantly, you will lose all the animation, but you can always update pipe value smoothly. In the end, it's 1 calculation per group and 1 value update per pipe.

And you'll lose the "wave" effect that we see on the FF. But, honestly, who noticed such wave feature existed? It's a gimmick that doesn't bring much to the game and is very harsh on the CPU.

That's very similar to what they ended up doing.

While the new proposed system seems better, I feel it will only actually improve performance on edge cases. If you are at a point where you have ups issues, which is the case for nuclear on big setups for exemple, you rarely have long stretch of pipes, mostly lots of intersections.

Hi @Dominik, thanks for your 1st FFF. And obviously, thanks for this rework you have done.
I'm also afraid, as djnono is, that UPS issues are mainly arising in megabases, where intersections are everywhere, even in nicely thought up builds.

The solution you have is I think the best one you have without making the fluid pipes overpowered (electric system solution).

But I'dd like to suggest another aproach to the UPS problem of fluids in the late game. Objects early game are moved mainly with belts, but in megabases/late game, we all know, whatever optimisations you can do, belts will always have more drain on UPS than trains + bots combo. Fluid can be moved by pipes and trains but do not have a usable bot equivalent (lets not talk about barrels ).

Why cant we have a late game solution to moving fluids without pipes? Like bots replace belts? Barrels are not a real solution, as assemblers cant use barrels directly, the add the whole barreling/un-barreling problem, you have to move empty barrels arround,... Nobody likes barrels. Sorry

Why not have a new placable mini fluid tank: one square meter. They would act as requester chests for fluids. This object would be filled by bots (maybe a new kind of bot, specially for moving fluids without needing to use barels). And assemblers could directly pump from them if they are in there fluid inbox position. The new bots would just take the fluids from the big fluid tanks, and move them to the mini fluid tanks. Really, 'just' a requester/provider combo for late game fluid transportation over small distances.

Helicopters can move water IRL: https://i.stack.imgur.com/5oMG8.jpg , Factorio bots should be allowed to do as well

Wether you like my proposition, thanks for reading till here. Love yall, thanks for the great game you give us. Chears!

That's called barrels.

Can you add blue and green columns to debug menu?

It's already there

Why not drop the entire fluid network on its own thread, using the proposed system, and handle the impact on the main update thread with a 1 tick delay ?

See, when writing it I totally forgot about the multi-threading. Yes, things like this should be possible and hopefully we will get to it too.

Have fun convincing Rseding to let you do this.
Then again, performance...


Some questions:
Do pumps, assemblers, refineries, chemical plants, and offshore pumps count as junctions?
What about tanks with 2 connections?
What makes you think that this will improve UPS in actual UPS-intense setups?

It's not barrels, it eliminates the barreling and emptying assemblers, and doesn't involve an extra item.

[bjorntfn]

Regarding UPS optimization I have a suggestion.
I'm not familiar with the game enough to know whether this is already happening, but it can't hurt to suggest anyway

What if we could disable the fluid simulation for a fluid network that has reached a "steady-state"?
Then re-enabling under certain conditions which have changed that network.

Take a nuclear (or boiler) power setup for example, with 1 water pump (1200 water / sec input), some pipes, and 11 (not 12) heat exchangers.

Eventually the water in the network will reach 100% full and there wouldn't be a significant change to levels/flow anymore.

The network would remain in this steady-state unless:
- New components added to network (pipes, sources of water, sinks of water)
- Existing components changed (deconstructed, upgraded, or otherwise changed their production/consumption)

The fluid simulation could be disabled when a steady-state is reached, eg when all network components are showing less than 0.1% change in fluids from the previous 60 ticks.

Steady-state disabled when the network changes and then the fluid simulation for that network needs to happen again.

If there were more exchangers than water available, assuming the exchangers have a constant/predictable draw then a steady state could still be obtained.

The amount of water available to each heat exchanger would settle at some value less than the optimal draw, lets say 50 units/sec, and then the network updates could just hold at that steady-state, until one of the conditions above changed to force the simulation to start again.

This assumes a predictable/constant supply and demand in the network, which might make it difficult to apply to oil processing (unless that becomes more predictable)
It would help to make steam power more viable for larger bases though.

[BlueTemplar]

Thank you, but I already made that suggestion 2 months and ~160 posts ago.
viewtopic.php?p=378984#p378984

Including the change needed : that fluid producers/consumers work in flows (1 unit every X ticks) instead of pulses ( Y units every cycle).

( And others did speak about two-"phases" simulation too :
viewtopic.php?f=38&t=62489&p=379663&hilit=state#p379663 )

[bjorntfn]

Ah thanks, I hadn't seen those discussions.
Good to know it has been suggested