Friday Facts #430 - Drowning in Fluids

[apriori]

Tiling 250×250 seems doable))

Code: Select all

  |→||→|
——|→||→|——
  |→||→|

Code: Select all

 ————————————
 ↑↑↑      ↓↓↓
————      ———
 ↓↓↓      ↑↑↑
 ————————————

Ugly but works fine)

[Maphizto]

Wait, I don't get the splitting of pipelines. In the example video there is only a pump placed on one of the two lines going out of the T-split. Why doesn't the line going down need a pump?

The line to the left is longer than 250 until the end.
The line going down is shorter.

The reason to suggest putting the pump at that point is not the distance between the two pumps (it's only about 15 tiles or so) but the distance to the end of the left line.

I'm also not sure what I'm seeing before the placement of the pipe on the left and this bothered me as soon as I saw it in the video. There is a pump top right.. why is it blinking? The red line and the x would indicate that both the left and down pipes from the pump on the right top are over the 250 limit, but do we actually see where the limit is or do just randomly place pumps and wait for the red xes to disappear? Is it the red blinking fluid symbol? just place a pump on there to fix it?

Also if the limit is a fixed value and we cannot extend dynamically with pumps.. removing and adding pipes to an existing sytem will shift the whole 250x250 boxes, wouldnt it? So if I place a pump at the 250 mark and then decide to spaghetti something at the beginning.. does this break the pump at the 250 mark?

[Koub]

1. When a pipeline exceeds the limit, make it so that only part that is outside the 250x250 area stops working, but pipeline that is inside continues to work.

That would be super weird. I mean in one pipe, everything flows, one meter down the pipe, everything is frozen. Even the not-so-natural "nothing flows if pipe network too big" feels less unnatural (at least to me).

[klogo_hopper]

That would be super weird. I mean in one pipe, everything flows, one meter down the pipe, everything is frozen. Even the not-so-natural "nothing flows if pipe network too big" feels less unnatural (at least to me).

Yes, maybe it is weird. But such behavior could be very roughly explained by lack of pressure for liquid to flow further. And that is precisely why we need to place a pump to push liquid further along the pipeline.

But in my opinion, it is no less weird that the pipeline completely stops working due to exceeding the limit. What is stopping it? If I remove the pipe that is located outside the 250x250 area, pipeline will magically start working again

[Breizh]

1 Water expands to 10 Steam in boilers and heat exchangers; they just consume 10x less water to make the same amount of Steam

Lame. There was a lowkey beauty in how water hungry nuclear energy is (given how dirt cheap uranium is) and you had to put an actual thought into designing your setups to ensure proper water input.

The pump now have a throughput of 1200/s instead of 12000/s so it’s the same, if you don’t build on a lake (and if you do, then water already wasn’t a problem).

[adam_bise]

Try to send fluids to another planet with [...] trains

I'm sure Renai Transportation will have a thing for that.

Or Jules Verne

[KuuLightwing]

If the same approach was used in relation to trains.

Old train network was not intuitive and sometimes frustrating to work with, especially when it comes to signals. It also can cause deadlocks which are hard to visualize and debug. So we decided to remove moving trains, and train network now just teleports items between stations. We understand that it is a huge step back in terms of realism, but fun is more important than realism.

We found out that our new train network works great but it became too simplistic, so we made it so it doesn't work unless you place signals every 250 tiles, but the game will tell you exactly where to place them, so it remains fun and interactive.

And we'll have comments like

- Such a great change! Train network was always so unintuitive and easy to deadlock, I never got the hang of it because of that, now it's much more accessible!

- Those who want the old way to remain because "realism" don't realize that it was so unrealistic - trains can't take tight turns at 300 km/h and nobody makes 1-2 trains in real life.

- I lol at those who want 1.1 trains back. They literally don't work because of all the deadlocks

Now, I jest of course, and this is aimed more at dismissive comments rather than the devs, but I wanna use this to demonstrate what in my opinion is the root of complaints about these changes. It's not that 1.1 fluids are so good (and yes, train network overall is a more solid system), or that the system is "realistic" - it had issues and I would like to see them fixed. But it does feel like instead of getting new train schedules, interrupts and all other tools that would improve the experience working with it, it got replaced with a super approximated abstraction that is much less interesting to use, despite claiming it being "interactive".

[SpecterNadir7]

1. When a pipeline exceeds the limit, make it so that only part that is outside the 250x250 area stops working, but pipeline that is inside continues to work.

That would be super weird. I mean in one pipe, everything flows, one meter down the pipe, everything is frozen. Even the not-so-natural "nothing flows if pipe network too big" feels less unnatural (at least to me).

While making it based on actual pipe length versus the area the pipe segment takes up seems more intuitive, I think my real problem with the system is the hard area limit, where suddenly once it exceed 250x250 is completely stops working. Honestly, the area limit will be less noticeable of a problem if it is instead a soft cap, where instead the max throughput diminishes the larger the pipe segment gets gradually, rather than an all or nothing.

I think that could even be represented with the visualization in a unique way, where the max throughput of a pipe segment could be represented in the thickness of the line drawn over the pipe, and when you have a really, really long pipe the line would be very thin (only a few pixels wide or something). That would be very obvious visual feedback that your pipe segment is getting too long.

[Mithaldu]

This Is going to make huge defense walls with flamethrower turrets much more expensive to run and set up.

Good. Flamethrowers have been extremely OP for years so I think making them more difficult is nothing but a good thing.

That's a good and valid sentiment, but making them more difficult by way of a completely full pipe magically being unable to provide even a trickle after 250 tiles feels just ass.

[KuuLightwing]

That's a good and valid sentiment, but making them more difficult by way of a completely full pipe magically being unable to provide even a trickle after 250 tiles feels just ass.

To be frank, as a nerf to flamethrowers that's just not going to work. They are so powerful for reasons unrelated to requiring no power to run, and making a wall mildly more annoying to set up, but still trivial nonetheless changes absolutely nothing in terms of their viability.

[Mithaldu]

I find a little disturbing that these two contraptions are equivalent

sorry for the big zoomed out picture

2024-09-27 20_28_54-Window.jpg

I'd have preferred a number of pipe+tank entities instead of an area (or maybe I missed something crucial).

this is a very good post

[chl]

The old fluid system, in my opinion, had an interesting emergent behaviour with fun problems to solve, especially when scaling up, much like belts. The new system with infinite throughput up to hard limit on the size of extents seems to go against that design philosophy. Of course, the old system had some issues and I have yet to play with the new system, I look forward to doing so and I'm trying to be optimistic. My biggest worry is that if a too simplistic system goes live it will be hard to make changes to make it more interesting without breaking peoples bases as well as causing community backlash, as the devs have described being the case with bots.

I also always liked the contrast between belts and pipes in terms of how visual their behaviours is. I think that is one of the reasons that larger builds involving pipes was how I started properly testing my designs.

Finally, I hope the devs don't cave to the chunk-alignment crowd, I want to see them in tears . The change to the range of the big electric pole was a huge mistake and I hope to not see it repeated.

[TheRaph]

I'm also not sure what I'm seeing before the placement of the pipe on the left and this bothered me as soon as I saw it in the video. There is a pump top right.. why is it blinking? The red line and the x would indicate that both the left and down pipes from the pump on the right top are over the 250 limit, but do we actually see where the limit is or do just randomly place pumps and wait for the red xes to disappear? Is it the red blinking fluid symbol? just place a pump on there to fix it?

Also if the limit is a fixed value and we cannot extend dynamically with pumps.. removing and adding pipes to an existing sytem will shift the whole 250x250 boxes, wouldnt it? So if I place a pump at the 250 mark and then decide to spaghetti something at the beginning.. does this break the pump at the 250 mark?

If one part of a segment is too long, the whole segment will stop working.
and yes the new red symbol is for "place a pump here to fix". But I looks like it count from the end and not from the last pump.

[Jap2.0]

Slightly tangential, but I was thinking the other week about major breaking changes by version:

2.0: train curves, large fluid networks
0.15: science, boilers
0.12: turrets, belt ends/corners

What others am I missing?

0.12 : the "you win" changed from building rocket defense to building a rocket silo, and sending a satellite with a rocket
0.13 : map gen change - although not breaking games, but chunks generated after that did not fit those generated before.
0.16 : another terrain generation change, red science pack recipe change, fluid wagon change (became single fluid starting from 3)
0.17 : simplified basic oil processing, science pack refactor

Oh yeah, a couple big ones I forgot there. I would say changing map gen is very obvious visually, but doesn't really break anything or require redesigns.

What was the red science change? Hasn't that been the same basically forever?

[Koub]

What was the red science change? Hasn't that been the same basically forever?

Sorry, my brain thought purple, and my fingers wrote red. Purple science pack changed twice : in 0.15, it started needing a pumpjack, then it was changed to be crafted with an AM1, which was removed in 0.16, and then again, it was changed in 0.17, to get its final recipe.

[vaderciya]

I've read a lot of the comments here and i just don't understand it. The example video was very unclear... why did the pump need to be placed?? because somewhere off screen the pipeline exceeded 250 tiles in total length? It's not respresented well if thats the case

And then there's the whole issue in general. Can somehow who really understands it, explain why we're trading the current fluid mechanics in 1.1 (where things just work in by balancing fluids) to this new system where we arbitrarily decide that "nope, the pipeline is 251 tiles long, it stops working completely, reduce it to 250 and it works perfectly".

I've agreed with and liked pretty much everything in the expansion up this point, but i just don't get it, and it seems a lot of other people don't get it either. I don't see how this helps anything?

[FasterJump]

I've only read the first 4 pages and a half of comments, but I just wanted to say that I support the idea of a gradual flow limitation, especially useful for lubricant and flamethrower pipelines, which can be very long.

I suggest that a segment between 257 and 512 tile wide/long would make all connected machines fill/empty flow rates reduced by 50% (multiplicatively).

And so on, if a pipeline is between 513 and 1024 segment long, all machines flowrated be decreased by 75% instead.

I don't like the idea of gradual flowrate decrease because if a pipe segment is 280 tile long, it could be difficult to notice the 10% flow rate penalty. But maybe there would be a workaround for that as well?

Or just keep the total flow interruption as it is when going over 256. Afterall, it's similar to how pumps are used for vertical pipes in some other factory game, and it's working fine, nobody complained about it (placing mk2 pumps every 50 meter or facing a total flow interruption if going over 52m)

The idea of using a water tower and a pressure variable seem cool, but I don't see that happen so close the the release.

[DanGio]

As others stated, the first video seems a bit weird.

09-29-2024, 00-43-55.png (328.14 KiB) Viewed 1053 times

I understand that the problem here is the bottom left pipe network area which we don't fully see and is too big. But why is the blinking so close to the pump on the right ? Won't this new system entice noobs to place pumps every 2 underground pipes ? It's hard to say based on 1 video without the entire context so I'm not claiming anything. But if the player would extend the pipe network to the south east again, just by a little bit, the fluid network would stop again, right ?

[Loewchen]

why we're trading the current fluid mechanics in 1.1 (where things just work in by balancing fluids) to this new system where we arbitrarily decide that "nope, the pipeline is 251 tiles long, it stops working completely, reduce it to 250 and it works perfectly".

1.1 updates all the fluid levels of all pipe connection one after the other, but the sequence in which the updates happen effect the flow speed in the different directions, so the greater the level differences the stronger the flow preference in certain directions becomes. Also the only lever to increase flow speed overall is the volume of the pipes themselves but you don't want to store more dead fluid just to fill bigger pipes. On top of that 1.1 fluids are relatively computational expensive.
2.0 will remove fluid flow and instead only allow for forced transfer between fluid segments and machines, removing all the issues described with it.

How the transfer between segments and machines is performed and how fluid segment sizes are limited are the only things that do not seem set in stone, I would prefer a reduction in transfer at the segment border over completely freezing a too big segment.

[Molay]

I've read a lot of the comments here and i just don't understand it. The example video was very unclear... why did the pump need to be placed?? because somewhere off screen the pipeline exceeded 250 tiles in total length? It's not respresented well if thats the case

And then there's the whole issue in general. Can somehow who really understands it, explain why we're trading the current fluid mechanics in 1.1 (where things just work in by balancing fluids) to this new system where we arbitrarily decide that "nope, the pipeline is 251 tiles long, it stops working completely, reduce it to 250 and it works perfectly".

I've agreed with and liked pretty much everything in the expansion up this point, but i just don't get it, and it seems a lot of other people don't get it either. I don't see how this helps anything?

To expand on what Loewchen said, another motivation for the rework is a requirement for higher flow rates. Between new "big crafters", beacons and modules and putting all those things at legendary quality with the quality system, those machines will be guzzling fluids like crazy and the old simulated system would have a very hard time to keep up with the input requirements, whereas the simplified system will work much better and predictably. Besides that there is performance, I think that's the other core motivation for the rework.

The reason for the artificial limit seems to be rooted in wanting to add some complexity back into an oversimplified system that lead that undesired player action, like building humongous pipelines as the "best option" for all use cases. I don't think the 250 tile HARD limit is any good at all personally, and really hope they opt for a gradual throughput decrease (or in steps), rather than the binary on/off they chose now, but that seems to be the main motivation as I understand it.