Friday Facts #416 - Fluids 2.0

Regular reports on Factorio development.
Mouldy
Burner Inserter
Burner Inserter
Posts: 6
Joined: Fri Jan 05, 2018 9:02 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by Mouldy »

Apologies if this was already asked & answered, but:

The wording for the new pipe flow specifically does not include "machines" in each fluid 'segment'.

Does this imply that machine pass-through, like steam boilers or heat exchangers, will be different fluid segments, meaning 50% throughput drop between each?

If that's the case, it would mean that 1 offshore pump can only feed a chain of 5 boilers, or 4 heat exchangers.
User avatar
raiguard
Factorio Staff
Factorio Staff
Posts: 607
Joined: Wed Dec 13, 2017 8:29 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by raiguard »

ctalkep_ wrote: Fri Jun 21, 2024 4:43 pm -1 from me
love the current pipes because they're sexy as fuck, just look at this, you can almost hear it gurgling by
Image
i see the flow animations no longer do their thing in the 2.0 previews and i bet the sound is gone aswell
The flow animations seen in the FFF are placeholders. I put a disclaimer in the FFF but many people seem to have missed it.
Don't forget, you're here forever.
User avatar
yngndrw
Inserter
Inserter
Posts: 47
Joined: Tue Mar 01, 2016 12:14 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by yngndrw »

Mouldy wrote: Fri Jun 21, 2024 11:57 pm Apologies if this was already asked & answered, but:

The wording for the new pipe flow specifically does not include "machines" in each fluid 'segment'.

Does this imply that machine pass-through, like steam boilers or heat exchangers, will be different fluid segments, meaning 50% throughput drop between each?

If that's the case, it would mean that 1 offshore pump can only feed a chain of 5 boilers, or 4 heat exchangers.
I'm not sure how it's been implemented, but if it was me I'd consider a pass-through as a regular pipe segment. I.e. Treat it as two over-lapping entities, the machine and a regular pipe.
Pikachar
Inserter
Inserter
Posts: 32
Joined: Wed Apr 19, 2023 9:16 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by Pikachar »

Honestly, I find this change to be a vast improvement. I mean, the old system didn't work every time anyway. Random pipe placement would change how flow worked. So, I find it to be a nice update.
User avatar
GregoriusT
Filter Inserter
Filter Inserter
Posts: 356
Joined: Wed Apr 10, 2019 6:42 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by GregoriusT »

TheFrizz wrote: Fri Jun 21, 2024 10:46 pm The teleporting fluids solution seems to completely eliminate puzzle #2. I cannot see the downside of just routing one pipe to every local production block that needs fluid X just like the electrical network. I guess it might create a kind of nuisance while walking you have to aim for the gap between undergrounds. And create a bit of routing problem for your train tracks. I guess I'll have to reserve judgment until I'm actually building the bases.
Teleporting Fluids does not actually matter for transport. I have used long Pipes from Oil Patches before and it just works even with the old System. Throughput matters, not Latency.

The reason people use Trains for Oil is because it is easier to modularize it with a simple trainstop than to connect a ton of pipelines to your Refinery. Laying Pipes (and Belts for that matter) is a huge PITA for any distance that isn't the closest patches. It is far easier to just lay rails and let the trains do it, with less risk of Biter interference, not to mention those same tracks you just laid can be used for Ores too, and any other resources and Outposts, its like building a Highway, except that it actually works unlike real life.

Also someone please tell me how spamming Pumps inbetween undergrounds is a frikkin puzzle, because that is what the old system forces you to do when you build big with beacons. Even oil pipelines dont really need THAT much in regards to pumps!

Not to mention the inconsistent behaviour that changes depending on how you rotate the blueprint or in what order the bots decide to build your pipes, things that you mostly do not have any control over. How is THAT supposed to be a puzzle?!

All the REAL puzzle aspects of the Fluid System still exist as far as I see. You still have to manage your different fluid pipes the same way as before, you still have to make sure that you have enough of the 3 oil products before cracking, and you still have to deal with Nuclear Reactor Water/Steam throughput.
Don't underestimate Landmines!
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
agmike
Inserter
Inserter
Posts: 35
Joined: Mon Apr 24, 2017 8:18 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by agmike »

I still remember the old FFFs discussing various new ideas and solutions to the fluid problem. One of them had improved algorithm that introduced flow rate alongside pressure and fixed the inconsistencies and junctions. I would have preferred seeing that implemented, but this is also an improvement from what we had before.

I am curious however why that old improvement was so silently dismissed.
mcdjfp
Long Handed Inserter
Long Handed Inserter
Posts: 82
Joined: Sat May 20, 2017 12:42 am
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by mcdjfp »

Probably because at some point UPS became the only real goal to allow as big a base as possible on as weak a computer as possible. Of course, at some point there needs to be a cutoff before everything is simplified to nothingness.
User avatar
JajajTec
Manual Inserter
Manual Inserter
Posts: 3
Joined: Thu Apr 09, 2020 4:47 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by JajajTec »

nova4x wrote: Fri Jun 21, 2024 5:28 pm My own two cents on this. I really like what new opportunities this opens up for how you structure your fluid network. The old system was quite restrictive and often required pump spam for high throughput builds and even then was still inconsistent leading to lost efficiency.

However I don't like the potential infinite throughput of a pipeline which, if supply is greater than demand, will eventually happen. Medium midgame bases would be easily supported by a single pipeline. I don't think that this is a problem though, in and of itself. The advantages are nice and very convenient and do let you discard some of that mental overhead of worrying about flowrate and janky fluid dynamics dependent on placement order.

The issue I have is with the implications that this makes your fluid production and movement feel smaller. Before as you needed to move more and more fluid that pipeline would take up more space within a specific build. Now it just stays static even with ever increasing throughput (as long as supply > demand). I'd like to propose an idea that would still allow for the pipeline to grow, fluid must flow. Something in the vein of limiting output throughput to a specific cap, where output equals fullness percentage or pipeline cap whichever is smaller. You would then still be required to run parallel pipelines to increase throughput. Since having a bunch of sprawling parallel pipes is annoying I propose having pipe tiers that increase throughput, with each tier being physically larger than the previous.

Then the size of the tiers could increase simply as follows. Tier I is the pipe we have now, simple and smaller with a lot of flexibility in its placement. Tier II could be 2x2 like a rail tile which would make it more limited in its placement but would have a greater throughput than just two side by side Tier I pipes. Tier III follows the same pattern, 3x3 but has more throughput than two parallel Tier II pipes. You get the idea.

Now you can easily dismiss this because the existing pipelines in reality are massive meter in diameter pipes. But I raise you that this is a game about excess, massive factories that are massive for the sake of it. I believe that larger pipes corresponding to higher tiers would fit right in with the notion of excessive production. With normal production you build more belt lanes or send out more and more trains. Pipes losing some of their "realism" leaves them behind because there doesn't appear to be much now which shows just how much fluid is being moved. I hope others can get behind my thoughts because this feels very inline with the type of progression you typically have in the game. At least I would much prefer it over pumping fluid into a tiny pipe and the magic of the game handles all fluid dynamics, feels a bit too hands off for me.

Edit: Grammar
i really like this. i always wanted BIG CHUNGUS pipes beside my BIG CHUNGUS factorys. and making them like the rail system will make them look so good!
I also understand why this change is implemented. but it just removes the challange and soul of the fluid system for me. the way it sloshes around, waves threw the network, the way it takes physical time to react to big influences far away and the pressure drops over distance... i would reeeeeeeaally miss that.
but i understand the benefit of it from a performence standpoint so i would begrudgingly accept it. so at least pleaaaaaaaassssseeee make big chungus pipes!!
maniak1349
Long Handed Inserter
Long Handed Inserter
Posts: 79
Joined: Mon Nov 03, 2014 12:28 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by maniak1349 »

It's a good change, but complete lack of challenge is a bit disheartening.
How about keeping a new mechanics and have a limited throughput for each segment? This way annoying problems with very low flow on long distances and unreliable flow due to build order will be solved. Yet moving large quantities of liquids around your base still pose some challenge. It will look more realistic too - you need more/bigger pipes to move more stuffs.
User avatar
BEEFE
Inserter
Inserter
Posts: 43
Joined: Sat May 25, 2019 1:13 am
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by BEEFE »

Kinda bummed that pipes seem to be losing throughput restrictions but overall this seems like a much more manageable, reliable, and efficient system than the old fluid simulation. Not sad to see that go!

I had a thought of how long pipes could have lowered throughput with the new system, something pretty simple: a segment has it maximum throughput decreased linearly (but very very slightly) with every pipe that's part of the segment. At the point where that starts seriously limiting throughput, you can simply shorten the segment by putting a pump in the middle. The formula for moving fluid between segments would be something like:

Code: Select all

some_constant * (tot_volume * filled_proportion) * (1 - 0.001 * (num_pipes + num_tanks*25))
and

Code: Select all

some_constant * (1 - 0.001 * (num_pipes + num_tanks*25))
for the segment being drawn from and the segment being filled, limited to the lower of the two.


In practical terms, throughput wouldn't be meaningfully limited by pipes shorter than 500 tiles unless you're consuming absolutely insane amounts of fluid, though you'd often want to put pumps right next to intersections whenever possible (again, if you're consuming particularly large amounts of fluid).

Tanks are weighted more heavily than pipes but mostly so it doesn't result in a degenerate situation where it's best to build a pipeline out of end-to-end tanks. They're still 10x as efficient as pipes in terms of storage volume divided by throughput penalty.


I'll whip up some diagrams about notable situations in a bit.
Loewchen
Global Moderator
Global Moderator
Posts: 9501
Joined: Wed Jan 07, 2015 5:53 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by Loewchen »

maniak1349 wrote: Sat Jun 22, 2024 12:55 am How about keeping a new mechanics and have a limited throughput for each segment?
A bases pipe network will only be one single "segment" for each type of fluid apart from pump separated branches for cracking or the like.
The pipe networks will essentially be like electric networks, one for each fluid and only separated by power-switches/pumps.
jamaicancastle
Inserter
Inserter
Posts: 23
Joined: Fri Apr 26, 2024 12:57 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by jamaicancastle »

GregoriusT wrote: Sat Jun 22, 2024 12:18 am Also someone please tell me how spamming Pumps inbetween undergrounds is a frikkin puzzle, because that is what the old system forces you to do when you build big with beacons. Even oil pipelines dont really need THAT much in regards to pumps!

Not to mention the inconsistent behaviour that changes depending on how you rotate the blueprint or in what order the bots decide to build your pipes, things that you mostly do not have any control over. How is THAT supposed to be a puzzle?!
To me, these "puzzles" feel like one of those murder mysteries where, 10 pages before the end, the author suddenly reveals something that the narrator knew all along that they just didn't tell you about it. They aren't fair, in the sense that there's no reasonable way for a player to understand them from what's given in game. You can only understand them if you perceive that something really strange and unexpected is happening, and then ask on the forums. That's not good gameplay, it's just an excuse to get people to read your forums. :P
agmike wrote: Sat Jun 22, 2024 12:23 am I am curious however why that old improvement was so silently dismissed.
I would imagine it's the same reason it wasn't adopted back then: too much extra performance overhead, not enough improvement.
gGeorg
Filter Inserter
Filter Inserter
Posts: 436
Joined: Wed Jun 19, 2019 8:06 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by gGeorg »

Loewchen wrote: Sat Jun 22, 2024 1:39 am
maniak1349 wrote: Sat Jun 22, 2024 12:55 am How about keeping a new mechanics and have a limited throughput for each segment?
A bases pipe network will only be one single "segment" for each type of fluid apart from pump separated branches for cracking or the like.
The pipe networks will essentially be like electric networks, one for each fluid and only separated by power-switches/pumps.
I think some of the people who say that it is the good change, didnt understand that "segment" could be whole base. No limit in size, even megabase is one segment. All is just one segment.
It is just one pool with connectors in/out. All connected virtually, therefore no issues with throughput because there is no "pipe throughput capacity", because there is, in fact ,no flow.

Fix the fluid system by removing flow, sounds somewhat Stalin : "Death solves all problems, no man, no problem."
nova4x
Inserter
Inserter
Posts: 25
Joined: Fri Jun 21, 2024 5:09 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by nova4x »

JajajTec wrote: Sat Jun 22, 2024 12:34 am
nova4x wrote: Fri Jun 21, 2024 5:28 pm My own two cents on this. I really like what new opportunities this opens up for how you structure your fluid network. The old system was quite restrictive and often required pump spam for high throughput builds and even then was still inconsistent leading to lost efficiency.

However I don't like the potential infinite throughput of a pipeline which, if supply is greater than demand, will eventually happen. Medium midgame bases would be easily supported by a single pipeline. I don't think that this is a problem though, in and of itself. The advantages are nice and very convenient and do let you discard some of that mental overhead of worrying about flowrate and janky fluid dynamics dependent on placement order.

The issue I have is with the implications that this makes your fluid production and movement feel smaller. Before as you needed to move more and more fluid that pipeline would take up more space within a specific build. Now it just stays static even with ever increasing throughput (as long as supply > demand). I'd like to propose an idea that would still allow for the pipeline to grow, fluid must flow. Something in the vein of limiting output throughput to a specific cap, where output equals fullness percentage or pipeline cap whichever is smaller. You would then still be required to run parallel pipelines to increase throughput. Since having a bunch of sprawling parallel pipes is annoying I propose having pipe tiers that increase throughput, with each tier being physically larger than the previous.

Then the size of the tiers could increase simply as follows. Tier I is the pipe we have now, simple and smaller with a lot of flexibility in its placement. Tier II could be 2x2 like a rail tile which would make it more limited in its placement but would have a greater throughput than just two side by side Tier I pipes. Tier III follows the same pattern, 3x3 but has more throughput than two parallel Tier II pipes. You get the idea.

Now you can easily dismiss this because the existing pipelines in reality are massive meter in diameter pipes. But I raise you that this is a game about excess, massive factories that are massive for the sake of it. I believe that larger pipes corresponding to higher tiers would fit right in with the notion of excessive production. With normal production you build more belt lanes or send out more and more trains. Pipes losing some of their "realism" leaves them behind because there doesn't appear to be much now which shows just how much fluid is being moved. I hope others can get behind my thoughts because this feels very inline with the type of progression you typically have in the game. At least I would much prefer it over pumping fluid into a tiny pipe and the magic of the game handles all fluid dynamics, feels a bit too hands off for me.

Edit: Grammar
i really like this. i always wanted BIG CHUNGUS pipes beside my BIG CHUNGUS factorys. and making them like the rail system will make them look so good!
I also understand why this change is implemented. but it just removes the challange and soul of the fluid system for me. the way it sloshes around, waves threw the network, the way it takes physical time to react to big influences far away and the pressure drops over distance... i would reeeeeeeaally miss that.
but i understand the benefit of it from a performence standpoint so i would begrudgingly accept it. so at least pleaaaaaaaassssseeee make big chungus pipes!!
Glad someone else likes my idea. They did mention somewhere that the graphics are placeholder so we may get some form of visualization for flow rate. On the discord they called this a mechanic nuke, as in taking it to the ground so new things can be done with it. I hold out hope that we get further iterations on this system and that it doesn't ship at release in the current state.
maniak1349
Long Handed Inserter
Long Handed Inserter
Posts: 79
Joined: Mon Nov 03, 2014 12:28 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by maniak1349 »

Loewchen wrote: Sat Jun 22, 2024 1:39 am
maniak1349 wrote: Sat Jun 22, 2024 12:55 am How about keeping a new mechanics and have a limited throughput for each segment?
A bases pipe network will only be one single "segment" for each type of fluid apart from pump separated branches for cracking or the like.
The pipe networks will essentially be like electric networks, one for each fluid and only separated by power-switches/pumps.
Yeah, I read the article.
Machines can push fluid into a segment at an unlimited rate, and can pull from a segment at a rate proportional to how full the segment is.
What I meant is - each of those large segments consisting of all of the connected pipes with same liquid to have the limited push rate. So you cannot push 10000000 water/s through a single string of pipes, you will need to separate them into multiple such segments.
Last edited by maniak1349 on Sat Jun 22, 2024 2:11 am, edited 1 time in total.
thermomug
Inserter
Inserter
Posts: 25
Joined: Fri Sep 08, 2023 1:51 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by thermomug »

I gotta say, this is the first change from 1.1 that I heavy dislike. It makes fluid handling stupidly easy and boring. Where is the attention to detail, like with belts?


"It just works"


Do you know, where this quote comes from??? We want 16 times the detail, not less detail !!!

Quite disappointed. (For the first time to be fair)
TheBuzzSaw
Burner Inserter
Burner Inserter
Posts: 9
Joined: Fri Sep 08, 2023 4:02 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by TheBuzzSaw »

I welcome this change because pipes just don't work currently. I've lost count of how many times I've seen a pipe with 100 liquid sitting next to a pipe with 0 liquid, and it just won't flow. While the "realism" would be nice, I want my liquid systems to actually work. I'm sure the devs can revisit this in the future and see about restoring the flow.
User avatar
mrudat
Fast Inserter
Fast Inserter
Posts: 248
Joined: Fri Feb 16, 2018 5:21 am
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by mrudat »

Calculating the flow rate for individual pipe segments for visualisation could be interesting, depending on how realistic we're attempting to be; I imagine you'd want to start from in/out flows from input/output fluid boxes and tanks.

I guess something like for each pipe segment, build a list of input/outputs to its left/right, pick the shorter list, add them up to calculate net flow, and that's the flow rate through that pipe segment.

There's room for optimisation, as many pipe segments share the same input/outputs, e.g. a straight length of pipe would have the same flow rate along its entire length, so should only need to calculate net flow once.

Perhaps have net flow available via circuit network?
eloepp
Burner Inserter
Burner Inserter
Posts: 6
Joined: Fri Jun 21, 2024 6:15 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by eloepp »

TheBuzzSaw wrote: Sat Jun 22, 2024 2:16 am I welcome this change because pipes just don't work currently. I've lost count of how many times I've seen a pipe with 100 liquid sitting next to a pipe with 0 liquid, and it just won't flow. While the "realism" would be nice, I want my liquid systems to actually work. I'm sure the devs can revisit this in the future and see about restoring the flow.
I think the majority of people agree that the current fluid system is flawed and often frustrating, what I also think many people were waiting for is an FFF on this exact topic about how they would improve upon the current system, like they did with many others. Admittedly, I have no idea how complex of an issue it is, must be quite hefty if Wube couldn't figure it out. They are probably looking at these comments thinking we are naïve, but as a laymen I was starting to think they could do just about anything.

I'm not even super upset about this change, it just seems like a step back in some ways, in the complex world of Factorio... something is getting greatly simplified...I'm not used to this in a game of great depth and problem solving. In 99% of other games I think most people like things being simplified, but I don't think Factorio and its player-base can be compared to most other games. To be fair, a lot of things are simplified, like his analogy with the assembling machines, I think it was, but it's easier to justify something that never was than something that has been in the game since the beginning. I know a lot of people will like this change, I just don't think "it just works" is what a lot of us were expecting.

who knows, maybe some new challenges will be introduced with fluids 2.0. I will be curious to see what people end up doing with their fluids...I'm bad at visualizing so I wont really know what it's like until I actually try it. I hope there are some deep and rewarding puzzles to figure out :D
maniak1349
Long Handed Inserter
Long Handed Inserter
Posts: 79
Joined: Mon Nov 03, 2014 12:28 pm
Contact:

Re: Friday Facts #416 - Fluids 2.0

Post by maniak1349 »

After some thought maybe my idea is not that great from players' standpoint. People will have setups with bunch of providers connected to bunch of consumers with a single line of pipes, eventually hit the throughput cap and try to solve it with obvious addition of pipelines in middle part. It won't work since it is still the same big section and people will get annoyed at how counterintuitive the whole thing is. So underlying mechanics will require a preemptive explanation, and some people just love to ignore the tips. Overall it will be kinda clunky.
Post Reply

Return to “News”