Friday Facts #430 - Drowning in Fluids

[Theikkru]

[...]Better as in makes more sense, less arbitrarily restrictive, and is more intuitive to the player.
[...]

Ah, right. I just think that, unfortunately, that's really unlikely to pan out, given that the devs are already eyeing things at O(1) complexity.

[protocol_1903]

Ah, right. I just think that, unfortunately, that's really unlikely to pan out, given that the devs are already eyeing things at O(1) complexity.

Sadly, it appears so. Although a lot of options are better than 1.1 fluid mechanics (gameplay and computational perspectives) i hope they do something with constraints that are a little less arbitrary

[HDL_CinC_Dragon]

I can't help but feel like a better fix for fluids would be a combination of fluids 1.1 with the flow calculation in this FFF except each pipe segment counts as a consumer so the fluid still flows AND still moves around as you'd intuitively expect...

[yngndrw]

I really like these changes, I despise the 1.1 fluid mechanics:
- The horrible balancing you have to try to do when unloading fluid wagons into storage tanks that never get used evenly due to the order-based fluid priority
- The mess of water pipes around any nuclear plant
- Pipelines made out of pumps

I think the two sets of changes in FFF-416 and FFF-430 will really improve things for the better and make the game far more enjoyable. But as others have mentioned, please match the block size with the new pipeline limit: 256x256.

My only concern with the pipeline area limit is about visualisation when using blueprints - Will the limit be highlighted as you're placing a blueprint so that you can see that placing that blueprint will cause a pipeline blockage before you place it down? Without some feedback mechanism during the use of blueprints, it will be very easy to mess up something off-screen.

[DefGie]

could go for a node based system where network flows, latency, and storage are precalculated between nodes (building connection points) when you construct the network to avoid constant runtime overhead.

or split pipes into separate networks (condition being where 2 pipe components never touch directly or by proxy) and add multithreadding to them.

Specifically, I'm still puzzled they didn't go with something that substitutes electric flow for fluid flow, i.e. based on ohm's law. Fixed resistance per unit pipe (/length of underground pipe connection) (less for quality pipes, if you want. A gift for the quality-haters). Fluid sinks have a negative pressure ("voltage") which can approach 0 as they fill. Sources (fluid production, offshore pump, storage tanks) have a positive pressure which could increase as they fill. Pumps create pressure deltas rather than flow directly. There's no flow latency like both iterations of 2.0 system that have been described.

I'm a bit rusty on the relevant math but I believe for any pipe network the system of equations can be solved symbolically (when a unit of pipe is added, changing the network, much less than every tick) to where the flow in/out of each source/sink is a linear combination of the pressure values in the network. Also flow through legs that only connect to junctions rather than sources or sinks, if you want to present that information to the player, but it's irrelevant to the logic/gameplay effects. I think the role of pumps in this would come out feeling a lot better than 1.1

Failing that, I'd still rather see what a few others have suggested (possibly my extrapolation), flow through a pipe network behaves much closer to the logic in this FFF but inversely proportional to the number of pipe units in the network, no "extents". Or falls off at a less aggressive rate.

Either approach would give us a more "organic" constraint - as players we decide what network size is impractical, and the use-case (some people mentioning long pipes for lube) is a factor - but we definitely don't get infinite throughput over infinite distance. That should feel more intuitive/realistic, which when it comes to "feel" are pretty much interchangeable - For the naysayers to realism.

But I guess in all of this is there a concern about having rules that leave the maximum feasible throughput too low?

[CeDoMain]

Here is what I think would feel a lot more natural, rather than it being an arbitrary area limit (which as I also saw some people say, how is that area determined?) there is a "soft" cap on the flow rate of the pipes based on the number of pipes in a pipe segment. Where each segment is determined by the number of pipes that are directly connected and not divided by pumps and other machines. [...]

I wanna base my proposal for a more realistic and intuitive system on this comment and similar ones.

In my opinion a fluid distribution system should prevent high throughput pipelines without (repressurizing) pumps, but also prevent big factories without (flow directing) pumps. At the same time long pipelines or very spaghettilike piperoutes through a factory with dozens of machines connected should be possible, but with very low throughput. Expecially for beginners and early game.

My idea is to extend the new system by a statically calculated MaxFlowRate. It is based on the concept of turbulent and laminar flow in a pipesystem. Laminar flow is the best and essential for high throughput. Junctions, openings (machines/pumps) and long pipes will work against laminar flow. When the flow become turbulent there is still throughput but a very low one. To get this behavior i would do this:

• Each segment has a MaxFlowRate R which caps the intake and outtake of its connected machines/pumps from/to this segment. Pumps which are (normally) connected to two distinct segments choose the lower R.
• R has a max of 100 % (6000/s) and min of 1 % (60/s). These values can never be exceeded and represent best laminar or worst turbulent flow.
• If you want warnings of low R there could be a menu option with a slider: "Warn me if a pipe segment has a max flow rate lower than X %".
  I would like this option.
• The current R could be displayed in the tooltip of each pipe or as a red/green color in map view. Together with some stats (see below) to make its understanding easier.
• R can be calculated as a function of for example:
  • N: The pipetiles between the farthest away machines/pumps in a segment. Or maybe the total pipetiles of a segment.
  • C: The count of connections to machines/pumps of a segment. Maybe count also T/+ shape connections of pipes. Dont know.
• Some easy Heuristics to get R could be:
  • For each count of N above 64 subtract 1 % from R.
  • For each count of C above 12 subtract 2 % from R.

I hope this makes sense. I someone else has written this already I'm sorry. I tried to read all posts.
I cannot say if my choosen values are good balanced. Its after midnight here... Someone who knows the builds of space age can balance this better.

[TheRaph]

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.

[spiro9]

And once again, I'll repeat my comment from "Fluids "2.0" topic - just make new system a setting or a mod to turn on/off. The fact that this simplified version of fluid handling is being forced on all players and not just the ones who'll buy SA is mindboggling to me.

I am sorry, but i agree with the last part of this post, i actually LOVE the fluid system of 1.1, only thing that maybe should be changed is that buildings do not consume fluid in the same order they are built like it does now..

So please make a setting (or a mod) to use the "classic" fluid system, this system just feels so natural.

I love all the other changes and can not wait to play to new expansion!

"Just" being able to toggle the fluid system is completely infeasible, sorry. The old system is gone, reduced to atoms.

This is an absolutely terrible idea, honestly. Respect to every other change being made, but to toss a system that, albeit was inherently flawed, in favor of another flawed, and arbitrarily flawed, system, is flat-out bad design. A lot of people have already stated they are concerned about the arbitrary 250x250 limitation, others about the change in general. It would be better to rewrite the existing 1.1 system than to throw out everything existing players know about pipe networks in favor of something that is so unintuitive due to being so arbitrary.

[EustaceCS]

> Pipelines are constrained to a 250x250 tile area

How about taking last step towards realism and introducing proper Water Tower like entity?

Dude ... what do you even mean with a "proper" water tower? Why are fluid tanks not "proper" in your opinion?

Fluid tanks are not proper in my opinion because I still can't understand a thing about them. In neither of three iterations (1.0 , 2.0 1.0 and 2.0 2.0 , if you'd allow me to label them this way). And I've beaten the game twice, 180 hours per try.
I'm not quite in the mood to elaborate further about this, especially since it likely have nothing to do with question of water towers.

Honestly, I'm not quite ready to explain how water towers work and why I'm mentioning these either. Partially because of mood, partially because my English proficiency degraded to the point where sometimes I have to check dictionary even for less tech-y things.
I can, however, TRY to explain my concern better.

Piping 2.0 2.0 needs some means to plan area piping ahead of time. And, by extent, visualize that area. AND justify whole affair with this new mechanics.
Some substation-like building but for improving pipe pressure in an area - like... you know... water tower - with explicitly defined coverage.
(and potential for bigger coverage per quality level (where available), and potential for additional NERFS in a form of limit of pipe segments per coverage area as a bonus for having it not abstract)
Current "POP! goes 250*250 tiles limit!" is not dependant on input pressure. Nor on total actual length of specific piping route. And it hits all of a sudden.
Causing, among other things, profuse braincell prolapse because after hours over hours of perfectly logical fiddling with solids logistics and electricity wiring this... water thing comes unexpected and unjustified.
Water tower, acting like substation-but-for-pipe-pressure, could've avoided all that mess (including shoehorning pumps as segment splits) while operating on same abstraction level with motor-less belts and wire-less pole-to-consumer energy distribution. AND being better to understand.

3 weeks till release is probably too late to move anywhere in that direction tho.
The developers did a pretty dramatic leap of faith with Pipes 2.0 2.0 already.
Backflip to some other scheme became a thing too costy to perform.
So... ugh... no idea why I'm writing all this stuff. I myself am supposed to attend more pressing concerns at Saturday 4AM. Instead, I'm trying to understand what specifically alarmed me in this week's FFF to the point that I've left my shell again and started talking despite obviously not having sufficient skills to talk about such stuff.

[Theikkru]

[...]
Current "POP! goes 250*250 tiles limit!" is not dependant on input pressure. Nor on total actual length of specific piping route. And it hits all of a sudden.
Causing, among other things, profuse braincell prolapse because after hours over hours of perfectly logical fiddling with solids logistics and electricity wiring this... water thing comes unexpected and unjustified.
[...]

I'm not convinced about the water tower idea, but this sentiment is at the same time evocative, hilarious, and something I can agree with. The hard 250 limit is, in being so arbitrary, both jarring and immersion-breaking.

[TheRaph]

Instead of using a 250*250 bounding box as the limiting factor the number of pipe segments should be the relevant number. It is far more realistic (which I know is not that important in game design) but it being realistic also makes it more intuitive.

Also instead of either 100% or 0%, the output should be a function relative to the number of pipe segments. For example 100% for 1-50 segments and then dropping near 0% at 300 segments. It might be worth to consider counting underground pipes and fluid pipes as multiple segments to balance long distance pipelines with distribution pipelines.

With that system a player could decide how much throughput their pipeline needs and therefore how often they need to place pumps.

+1

[mocore]

Can we have more fluid tanks please, with more appealing visuals? Similar to what pY Coal Processing offers.

[sarge945]

A lot of effort seems to have gone into balancing pipes vs wagons, but unfortunately barrels seem to have been (once again) completely forgotten about and are now likely even more useless.

This part made me particularly sad

Will you choose the near-instant transportation of a pipeline, or the enhanced flexibility of a fluid train?

The quote should be more like this:

Will you choose the near-instant transportation of a pipeline, the enhanced flexibility of a fluid train, or the inconvenience and awkwardness of fluid barrels?

While I understand that barrels do still have some niche uses (although the fluid wagon capacity increase somewhat mitigates some of this), and are the only way to carry fluids via bots, are there any plans to address barrels in the future to make them more generally viable for certain playstyles?

[Jap2.0]

250x250

chunk division is 256x256

250 pipe + 2 pump = 252 length

I am in physical torment right now

2 tiles of pump on each side, so 254.

[GregoriusT]

A lot of effort seems to have gone into balancing pipes vs wagons, but unfortunately barrels seem to have been (once again) completely forgotten about and are now likely even more useless.

This part made me particularly sad

Will you choose the near-instant transportation of a pipeline, or the enhanced flexibility of a fluid train?

The quote should be more like this:

Will you choose the near-instant transportation of a pipeline, the enhanced flexibility of a fluid train, or the inconvenience and awkwardness of fluid barrels?

While I understand that barrels do still have some niche uses (although the fluid wagon capacity increase somewhat mitigates some of this), and are the only way to carry fluids via bots, are there any plans to address barrels in the future to make them more generally viable for certain playstyles?

I do like Barrels honestly, they are convenient in situations where you just dont want to setup any long term infrastructure, or want to be ready for any Fluid Recipe you might need randomly while not at Base. Also when using Barrels with Logistics Bots, if you really do not like laying Pipes.

Edit: Now I really want Logistics Requests for Cars and Tanks...

[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?

[Molay]

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

What others am I missing?

Don't remember the version, but belt corners was also a huge one. I guess it did not break anything as such, but it made a lot of previous designs obsolete as items no longer moved more slowly in curves.

[Jap2.0]

Don't remember the version, but belt corners was also a huge one. I guess it did not break anything as such, but it made a lot of previous designs obsolete as items no longer moved more slowly in curves.

True, I'm familiar with that but it was before my time. I couldn't figure out from the changelog on the wiki, but that reminded me of belts pushing items off the end, which was 0.12.

Edit: corners might also have been 0.12?

[Theikkru]

[...]are there any plans to address barrels in the future to make them more generally viable for certain playstyles?

How's this sound:

[...]I think it would also be a nice niche use case for barrels if they could be unloaded without power, albeit very slowly.

[GregoriusT]

Barrels would be so much nicer if they contained twice the amount of Fluid per Barrel, and everything else stayed the same. That way the Cargo Wagons filled with Barrels will not need more Slots, and the per Barrel Stacksize would stay the same.