Friday Facts #416 - Fluids 2.0
Re: Friday Facts #416 - Fluids 2.0
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.
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.
Re: Friday Facts #416 - Fluids 2.0
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.
Re: Friday Facts #416 - Fluids 2.0
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.Mouldy wrote: ↑Fri Jun 21, 2024 11:57 pmApologies 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.
Re: Friday Facts #416 - Fluids 2.0
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.
- GregoriusT
- Filter Inserter
- Posts: 265
- Joined: Wed Apr 10, 2019 6:42 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.TheFrizz wrote: ↑Fri Jun 21, 2024 10:46 pmThe 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.
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...
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...
Re: Friday Facts #416 - Fluids 2.0
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.
I am curious however why that old improvement was so silently dismissed.
Re: Friday Facts #416 - Fluids 2.0
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.
Re: Friday Facts #416 - Fluids 2.0
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!nova4x wrote: ↑Fri Jun 21, 2024 5:28 pmMy 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 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!!
-
- Long Handed Inserter
- Posts: 74
- Joined: Mon Nov 03, 2014 12:28 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.
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.
Re: Friday Facts #416 - Fluids 2.0
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:
and
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.
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))
Code: Select all
some_constant * (1 - 0.001 * (num_pipes + num_tanks*25))
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.
Re: Friday Facts #416 - Fluids 2.0
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.maniak1349 wrote: ↑Sat Jun 22, 2024 12:55 amHow about keeping a new mechanics and have a limited throughput for each segment?
The pipe networks will essentially be like electric networks, one for each fluid and only separated by power-switches/pumps.
-
- Burner Inserter
- Posts: 13
- Joined: Fri Apr 26, 2024 12:57 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.GregoriusT wrote: ↑Sat Jun 22, 2024 12:18 amAlso 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?!
![Razz :P](./images/smilies/icon_razz.gif)
I would imagine it's the same reason it wasn't adopted back then: too much extra performance overhead, not enough improvement.
Re: Friday Facts #416 - Fluids 2.0
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.Loewchen wrote: ↑Sat Jun 22, 2024 1:39 amA bases pipe network will only be one single "segment" for each type of fluid apart from pump separated branches for cracking or the like.maniak1349 wrote: ↑Sat Jun 22, 2024 12:55 amHow about keeping a new mechanics and have a limited throughput for each segment?
The pipe networks will essentially be like electric networks, one for each fluid and only separated by power-switches/pumps.
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."
Re: Friday Facts #416 - Fluids 2.0
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.JajajTec wrote: ↑Sat Jun 22, 2024 12:34 ami 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!nova4x wrote: ↑Fri Jun 21, 2024 5:28 pmMy 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 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!!
-
- Long Handed Inserter
- Posts: 74
- Joined: Mon Nov 03, 2014 12:28 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
Yeah, I read the article.Loewchen wrote: ↑Sat Jun 22, 2024 1:39 amA bases pipe network will only be one single "segment" for each type of fluid apart from pump separated branches for cracking or the like.maniak1349 wrote: ↑Sat Jun 22, 2024 12:55 amHow about keeping a new mechanics and have a limited throughput for each segment?
The pipe networks will essentially be like electric networks, one for each fluid and only separated by power-switches/pumps.
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.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.
Last edited by maniak1349 on Sat Jun 22, 2024 2:11 am, edited 1 time in total.
Re: Friday Facts #416 - Fluids 2.0
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)
"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)
-
- Burner Inserter
- Posts: 6
- Joined: Fri Sep 08, 2023 4:02 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.
Re: Friday Facts #416 - Fluids 2.0
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?
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?
Re: Friday Facts #416 - Fluids 2.0
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.TheBuzzSaw wrote: ↑Sat Jun 22, 2024 2:16 amI 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'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
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
-
- Long Handed Inserter
- Posts: 74
- Joined: Mon Nov 03, 2014 12:28 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.