Friday Facts #416 - Fluids 2.0

[FuryoftheStars]

fast (one-pass presumably)

The old system was single pass. That's why the build order could have an affect in designs that weren't producing enough for the demand.

The new system is a "no pass" within segments, which are broken apart only by machines and pumps.

[functional]

There is no point in fluids if they are simply power with different connectors.

Have you heard of oil processing?

[Panzerknacker]

There is no point in fluids if they are simply power with different connectors.

Have you heard of oil processing?

Man just give up already, why do you keep trying? Your arguments went from weak to absolutely null.

[functional]

Man just give up already

I thought you were the one who plans to quit if these changes go through? Seeing as they obviously will, I suppose it won't be me giving up innit? (Though I know you wont quit, but it's still funny)

[Koub]

[Koub] OK enough is enough, the immense majority of this thread is just the same handful of people repeating ad nauseam the same arguments, with a sprinkle of personal attacks. Thread locked.

[OCTAGRAM]

I came too late to discussion of Fluids 2.0. One thing catched my eye

As a special case, pumps can pull at a faster rate if they are connected directly to a storage tank

And what is a storage tank?

Pipes, underground pipes, and storage tanks are merged into fluid "segments".

Alright, so I can do special cases just anywhere. I end every pipe with a storage tank, then place pump, and it becomes a special case, pumping at faster rate than pipe normally can.

I think, storage tanks should be like machines, not part of fluid segments, or else there should be no special case.

Regarding infinite throughput of long pipes.

Each segment inherits its volume from the fluid boxes that comprise it and can hold one fluid.

Throughput limit through long pipes can be calculated statically as a matrix of input-output, and that limit may be applied as an additional restriction to pulling ability. But that square matrix can be very big, so maybe replace it with input-output coordinate distance, even if pipe makes a labyrinth. Segment has a volume, but this volume is dynamically divided between inputs. When output pulls, the rate is limited by distance to the input that contributed the volume to be pulled.

If storage tank is a machine, that may be realistic enough

[Koub]

[Koub] OK I'm trying to unlock the thread, since there was a useful post that should have ended here, hopefully those polluting this thread will have found something more constructive to do. Will relock it promptly if it derails again.

[gnutrino]

I think, storage tanks should be like machines, not part of fluid segments, or else there should be no special case.

I've wondered about that, I think the issue is that they can both be sources and sinks depending on the state of the rest of the network and can possibly be connected across different networks or have multiple connections onto the same network depending on connectivity elsewhere and I'm not sure how you could make that work while still being performant enough for large numbers of storage tanks.

Throughput limit through long pipes can be calculated statically as a matrix of input-output

I've tried a few times to come up with a suggestion for something like this (using one of the max-flow algorithms in my case) to keep some complexity/realism while pushing the expensive calculations outside of the main update loop but there's always some weird edge (and sometimes not so edge) cases that don't work. Notably it has to be able to deal with filling up a network with no sinks and draining a network with no sources and ideally not allow cheeses involving setting up false sources/sinks using pumps to artificially increase the calculated throughput. Creating a separate fluid box per input and calculating the outflow separately is an interesting one I hadn't thought of but, again, I'm not sure how much that would impact performance...

[GregoriusT]

Could the Tank throughput Issue be just solved by nerfing the regular Pump to only be able to output 100 fluid per update at once (one pipe) instead of 12000 per second? Wait no it's already 200 per update, it only would halve the whole thing to nerf it this way. But this does make me think that the pump might not be as OP as we guessed so far.

Offshore pumps should still have the same rate as before though, otherwise nuclear reactors might break a bit too hard. Would be interesting for Steam Engines though, since the new System would make branched pipes for multiple offshores more feasible, making water pond surface area important.

[OCTAGRAM]

Excluding special case would be a valid thing then.

Performance may be improved by making calculations on chunks, not individual cells. If we want long distances to work bad, chunks would do.

[MeduSalem]

Excluding special case would be a valid thing then.

Performance may be improved by making calculations on chunks, not individual cells. If we want long distances to work bad, chunks would do.

Which would be awkward.

Imagine a pipe section that is only 2 pipe tiles. 1 tile is in one chunk and the other tile is in the neighbouring chunk and the throughput sucks only because you make calculation based on chunks.

[aka13]

I will do violent things if I have to deal with chunk retardation that is all minecraft industrial mods in factorio.
Yes I am looking at you Greg with your exploding multiblocks

[bobucles]

Wait, all pipes are just one gigantic magic storage tank? A single string of spaghetti solves everything, everywhere? I get that the devs place high priority on CPU cycles, but that's going too far!

There may be a good way to simulate pipe flow limits. Take a single long line of pipe. A certain amount of fluid can go in, and a certain amount can go out. We know this, we've done the calculations a million times. When those end point limits are reached, you don't really need to know anything about the middle. The pipe has been "saturated" and those endpoints have the final say on flow rate. You can skip the calculations for the main meat of the pipe, without losing too much of the intent.

What if these pipes used a similar system? The two key factors would be the input fluid rate (saturation), and the size of that total pipe segment(resistance). Input fluid adds to saturation, and longer pipe segments reduce the saturation limit. Pumps would split the system, creating smaller pipe segments to keep the saturation limit high.

An individual pipe won't be able to do it all. The input saturation limits how much can go into a pipe, and if a pipe can't get more input, it can't do more output. Multiple pipes would need to run side by side to create more input channels to increase throughput. Pumps would still improve long distance throughput by resetting the saturation decay (this is much more easily modded, x pipe gives y limit, its just a lookup table, but programmers have complete control over it). The UI would need some assistance for highlighting pipe segments and showing pipe saturation, but that's the biggest obstacle I can think of. Perhaps there is a clever spaghetti exploit to get more flow rate from jank setups, but large scale pipe resistance will punish spaghetti and encourage short pipe segments with predictable behavior.

Consumer saturation doesn't matter too much. If more fluid can not enter the network, more fluid can not be used. A pipe is limited by how quickly it can fill, so no matter how quickly the fluid exits the previous pipe, the next input will impose a new saturation limit. Individual consumers also tend to have mortal flow rates (10-100/sec?) compared to the huge surge of flow from various supply sources (train cars and such trying to dump 4000/sec?). If only the input of the system is rate limited, there isn't too much damage that can be done on the output.

There may be some O(uhoh) issues with pipes becoming uncomfortably large. The pipe resistance helps to keep that in check by discouraging pipes over a certain size. But I imagine the pipes could still get pretty huge, just not like a solid continent of pipe huge.

In terms of sharing=caring, an uncapped output flow rate ensures that all machines have fair access to the pipe. Uncapped output kinda matches normal pipe use, where one main artery forks into many capillaries that feed many machines. If the pipe doesn't have enough internal storage to feed everything, there is no inherent sharing and it would have to be explicitly provided.

How would storage tanks work? Well, they would probably be treated as their own pipe network, splitting off from normal pipes. Tanks need insane saturation limits, such as for trains loading and unloading, but the pipe connection would retain the "normal" saturation limit for the rest of the pipes. Walls of storage tanks would have insane flow rates going through them, which is fine because vanilla tanks do that anyway. It would also allow buffer tanks to work in a similar way to pumps, cutting pipe segments to improve flow rate and such. I dunno, I can't see far beyond that.

[GregoriusT]

I will do violent things if I have to deal with chunk retardation that is all minecraft industrial mods in factorio.
Yes I am looking at you Greg with your exploding multiblocks

Luckily in Factorio ALL chunks are loaded at all times, so there isn't such an issue, like with the shitshow that is Minecraft, lol

[Panzerknacker]

Yeah we gotta come up with something better before Space Age comes out otherwise we'll be stuck with the new minecraft mod system forever.

[TheCraiggers]

It seems to me that some of these problems could be solved with a hybrid approach. Treat each segment as a single entity as in the new fluid system, but also calculate the length of that segment and lower the output in a non-linear way. For smaller segments, like in your oil refinery, you wouldn't notice it. But larger segments (like those spanning across continents to oil pumps) would be less efficient and would require pumps just like in the real world. It's still an abstraction though, and will probably create other issues later, like almost all abstractions do.

Storage tanks might still be a problem due to how they currently operate. Personally, I've always felt that "tanks are just a huge pipe" made little sense. Either you should have a pump to force fluids in (tanks where the fluid goes up, against gravity), or you should need a pump to get fluids out (tanks where the fluid falls into a reservoir and you need to pump against gravity to get them back). Getting both, for free, was always weird in my mind. I think part of the issue people are having with these changes are due to this storage tank behavior. Again, it's how abstractions work. They do simplify things, true, but there's always a cost when the system becomes more complex.

Now, as the post mentions, there comes a time in game dev where you need to throw reality out the window and focus on fun. And maybe this is one of those times. But I also think that this system will change the "meta" in what is the most efficient way to move things like oil. And maybe that's OK? People will find the most efficient way, regardless of what it is, regardless if it makes sense or not, just like we always have. It's not necessarily better or worse... just different. The fact that different feels worse is just an illusion.

[kitters]

Phew. I have read first 6 pages one day after FFF, wrote a comment like 'electrical fluids', 'imagine one big chest instead of belts', 'fluids are second type of items, you're cutting game in half'.
Today I returned here, tried to fish up arguments from both sides from 20 pages of holy wars. It was a great read. Sometimes. Rarely. Some of you even have build new systems in 'ideas and suggestions'.

I have an idea.

In an attempt to avoid a total rewrite, we first tried increasing throughput by increasing pipe volume. This "solved" the primary issue of low throughput with the trade-off of massively increasing buffer sizes. Storage tanks became effectively useless, and defensive walls utilizing flamethrower turrets were buffering tens of thousands of units of fluid, sucking bases dry.

Why just don't add new types of pipes with different volume (therefore, throughput)? To use small ones long defensive walls flamethrowers, and huge ones in crazy legendary speed beacon builds like those were shown in FFF. So that becomes a solution without a drawback. (Want them to still be 1*1. Some 'polymer coated pipes' from steel and plastic to lower friction or smth.)

p.s. After searching for keywords on forum I found a poor guy who talked about tier pipes (among other things), but don't have any reaction from loud guys screaming here, despite trying to engage in discussion with them and push a link to his original post several times.

So, why is this bad solution, people?

[GregoriusT]

Making it so Quality Pipes have more Capacity (100, 200, 300, 400, 500) could make sense for this as a solution, after all we got Quality Inserters too as Kovarex so gloriously demonstrated to be mass producing in a later FFF.

(i still like the reduction of lag and improved stability of the new system though)

[Panzerknacker]

That's not a bad idea at all from you.

[coppercoil]

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".