Page 9 of 24

Re: Friday Facts #416 - Fluids 2.0

Posted: Fri Jun 21, 2024 11:57 pm
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 12:01 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 12:05 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 12:15 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 12:18 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 12:23 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 12:32 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 12:34 am
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!!

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 12:55 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 1:07 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 1:39 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 1:51 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 1:54 am
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."

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 2:04 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 2:10 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 2:10 am
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)

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 2:16 am
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.

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 2:28 am
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?

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 2:42 am
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

Re: Friday Facts #416 - Fluids 2.0

Posted: Sat Jun 22, 2024 2:56 am
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.