Friday Facts #430 - Drowning in Fluids

[GregoriusT]

So here is the Ideas that seem to make the most sense to me:

1. Have the current Bounding Box Solution with the instant cut off of pressure, but 256x256 instead of 250x250.

2. Gradual throughput decrease based on Entity Count in the Pipe Network, once something like 200 pipe length have been placed.

3. Gradual throughput decrease based on Total Capacity of the Pipe Network, once a certain Capacity (I suggest 30000) has been reached. This will cause large Fluid Tanks to make everything slower if they are not hooked up to Pumps, while one singular Fluid Tank plus 50 pipes would still be fine.

[spacedog]

"What you see is the system as it will be when 2.0 launches, but I will continue tweaking and iterating on it in the future."

Just... ugh. I like the overall changes a lot, but please try to prioritize finalizing this before launch. It's going to be SUPER frustrating if we're trying to build things and fundamental mechanics are changing out from under us from patch to patch. This is the kind of thing that can break people's bases. Breaking changes are bad. The thought of possibly having to spend time fixing my base whenever there's a patch is most unwelcome.

This is not the way.

[Lithane]

Honestly the extents thing sounds like it will be really annoying for bigger bases.

It may be a change aimed at long distance pipes and trains, but when building a base in a mod with a lot of different fluids and big bases, it means that low-throughput utility fluids suddenly need double-pump arrangements all over the place to keep stuff moving because instead of just being slowed down they'll get stopped entirely.

I don't really see what you mean, adding a pump once every chunk on a pipeline is nothing crazy, at present you have to place them far more often to maintain flow rates. If it's something that's truly low throughput and you just need it once in a while, make a train, or transport it by bot in barrels. This current iteration seems quite a bit better than the last one they showed.

[Panzerknacker]

Is there really no way to improve the old system? Could you multithread it by letting the main thread only update pipe segments that are directly connected to machines (pumpjack adds fluid, assembling machine draws fluid) and then let all the other segments be calculated in paralel by another core, dumping the results in a table and signaling when ready, then the main thread can render using that table which should be in CPU cache.

Maybe some logic can be baked in that makes sure that at T-sections, both adjecent segments are treated equally instead of letting it depend on build order?

Where can I read how it really works on the inside? Will be easier to come up with something useful then.

[Koub]

Where can I read how it really works on the inside? Will be easier to come up with something useful then.

https://factorio.com/blog/post/fff-260
https://factorio.com/blog/post/fff-271
https://factorio.com/blog/post/fff-274

And the 2.0 stuff :
https://factorio.com/blog/post/fff-416
https://factorio.com/blog/post/fff-430

[ryanalpasta]

I am so pumped (pun intended) for this release, i've been following this for so long, definitely my favorite game and I'm so happy that y'all have done SO much with the update. You've definitely pushed it so so so much farther than any mod every could, which is really exciting. You also all clearly play the game, and every change you've made really feels like it's made with love for the unique experience that this game is, even if not everybody agrees on it!

I will potentially force myself to not buy it on launch cause i'm in the middle of writing my thesis and I don't want to, well... you know how it goes. BUT this will likely be my reward when i'm done )))

[gGeorg]

256 X 256 is too big.

Some facts :
Chunk is 32 x 32
City block is 100 x 100
https://youtu.be/FPJWak8z_nE?feature=shared&t=174

To finish game, factory which makes 60 science per minute is enough.
Factory size to finish the game fits into 256 x 256 frame.
So majority o those who are able to finish the game, do not notice any flow challenge.
Less than half of customers ever finished game.
---------------------------------------------------------------

If game designer plan to introduce flowing fluids to wide audience, but avoid mega-base minority fans annoyance. Then smaller fluid frame would be wise. Although make fluid frame size of a chunk could be annoying.

Perhaps make fluid frame size of a city block ?
That allows nice mega base blueprints, also introduce flow challenge to majority of players who actually finish the game.

[Zeg]

Just a minor point of clarification so I can visualize it better: How would that 250x250 area be aligned (I'm assuming it's rectangular and not circular)?

The words from the FFF: "Pipelines are constrained to a 250x250 tile area, and exceeding this limit will cause all flow through the pipeline to cease."
I understand it's a 250x250 tile square area. Given a list of coordinates (the coordinates of all the pipes), it's very easy to compute an enclosing square. So, after the engine created the segment, it computes its enclosing square. Then it checks if one side of that square is longer than 250, and if this is the case, the whole segment is marked as invalid and no fluids are transported within the whole segment. There is nothing cut off, no artificial border to just stop flowing the fluid too far - it's the whole segment that has been invalidated.

It is as if some bureaucrat prohibits the use of a perfectly fine finished pipe, because it violates some regulation. You know, bureaucracy is the single most powerful skill in any gaming environment: it can stop everything happen with the snip of a finger.

The bounding box limit really feels like the most arbitrary thing, if it works like it seems to be suggested. If we want to talk about placement order of pipes mattering, it seems like we could now get a user experience problem rather than a computational problem:

Pump facing east
Place 250 pipes eastward, all good
Place 249 pipes extending south from the end of the east run, all good

Then two possibilities:

1. Place one more pipe southward, pipe breaks, player logically realizes the pipe has been made too long
or
2. Place one more pipe north making a T-junction immediately at the pump output, pipe breaks for seemingly no logical reason

I agree with the idea that it would be better if only the pipes that extend beyond the 250 box would stop working, but then we're back to placement order mattering again, depending on how the bounding box is recalculated when you add or remove pipes.

[linktothepast83]

After thinking about it with the current system i would rather have an additive decrease in flow of 50% after every certain pipe length and to have an optical indication (in the alt icon visualization) in the pipe that the drop happens than the chunk instant cutoff. It would feel more natural, not forced and still with the optical indication of the pipe the sudden drop happens more easy to deal with than 1.1.

[Zlutz]

The 250x250 pipeline limit is just few tiles off the chunks multiple. Please make it 256x256

I wonder if you could somewhat easily cheat on the pipeline size limitation just by placing bidirectional pumps everywhere with logic to pump only when target fullness is smaller (by some margin) than source one. A bit cumbersome, but functional imho

That actually sounds like THE solution - just make "balancing pumps" between pipe chunks and you don't really have to care about it.
Might be fun though, pumps are not as fast as before so you might have to put extra pumps in some directions to compensate. Could create fun problems to solve.

[EustaceCS]

Got the final piece of puzzle which Intuition tried to pass to me.
Well, long story short... if brand-new pipe clustering system would piss me enough - I'll switch to conveyor belts and barrels.
Maybe, thanks to logi-bots getting performance improvement, I'll even resort to "infinite pipeline" made of belts, with logi bots distributing accumulated liquids to clustered liquid consumers. If (big if) I'll be unable to route barrels back and forth.
It's time to learn how to build belt-centric (instead of my usual lazy and disbalanced logi bot centric) factory anyway.
I hope new stack inserters can stack barrels, it'll make things easier by ALOT.
(thanks gods the game offers more than enough tools to solve specific problems)

[AileTheAlien]

Fluid wagons have been buffed to 50,000 (2x increase).

Not sure why that change was ever needed. You can build trains with how many wagons you want, there was no issue with fluid trains throughput.

In my games, I usually ended up with solid-trains that were two engines and four wagons, and liquid-trains that were only two or even one wagon long. The fluids were always more dense, for the recipes. I even did far away nuclear-steam-powered outposts, with a single solar panel to jump-start them if they ever ran out, but then got more steam delivered. (Sorry if this was already discussed. It's 14 pages of comments, and I'm sick today. )

[KuuLightwing]

In my games, I usually ended up with solid-trains that were two engines and four wagons, and liquid-trains that were only two or even one wagon long. The fluids were always more dense, for the recipes. I even did far away nuclear-steam-powered outposts, with a single solar panel to jump-start them if they ever ran out, but then got more steam delivered. (Sorry if this was already discussed. It's 14 pages of comments, and I'm sick today. )

Yea and even before this fluid wagons were definitely far superior for metal transport (as fluids). It's solid wagons that probably need some buffing.

[starpuppy]

TL;DR

A pressurization system to fluids.

09-29-2024, 20-32-26.png (824.99 KiB) Viewed 706 times

What?

Fluid systems are limited by a single type of fluid in the first place. instead of giving each pipe it's own variables, it simply joins/forms together a fluid system

Each fluid system will then have pressurization and storage amount,
pressurization would be the dormant result of initial input, giving a value of pressurization, then that value would be correspondent to the actual output of that fluid....

So instead of a total network of universally accessible fluid, or a system where each pipe and machine has a flow and push value as in present factorio.

You have a method of inputs that increase pressurization, machines that take in that input based off of said pressurization, machines could probably instead have their own inertia amount of pressurization that they add to the system.

So flow is based off of fluid system pressurization, 1 pressure equals +10 input/output, ( note these numbers are just thrown out as an example based on vanilla factorio.) There are [Output] and [Intake], output sources input a fluid to the system, intake takes, these follow the system of pressurization.

Each pipe would naturally lower pressurization. and to include methods of increasing pressurization there could be ideas of adding more inputs, adding more pumps, or potentially even machines/etc to increase it.

Why ?

I think the current idea for the new method of fluid is insufficient, i think it counters factorio's innate nature and is a unneeded hard block. I believe this method or in even partial degree would be valid to utilize.

[Wockes]

In my games, I usually ended up with solid-trains that were two engines and four wagons, and liquid-trains that were only two or even one wagon long. The fluids were always more dense, for the recipes. I even did far away nuclear-steam-powered outposts, with a single solar panel to jump-start them if they ever ran out, but then got more steam delivered. (Sorry if this was already discussed. It's 14 pages of comments, and I'm sick today. )

Yea and even before this fluid wagons were definitely far superior for metal transport (as fluids). It's solid wagons that probably need some buffing.

Maybe, during a normal rocket only vanilla run I don't even use trains I just spam belts everywhere since it's faster than spending hours setting it up

[Erichteia]

TL;DR

I suggest a mechanic to soften the hard 250-tile limit cut-off for fluids using the existing front and backpressure mechanics. This allows players to go slightly beyond the 250 tiles without a sudden collapse. I also give some ideas how this mechanic can be visualised to the player.

What ?

The idea is to replace the hard cut-off (you need to place a pump every 250 tiles) by the following formula:

Code: Select all

Fluid input/output rate ~ f(fluid level)*min(cutoff_length/pipe_length, 1)

f(fluid level) is the existing function relating the fullness of the pipes to the speed at which a machine can input/output the fluid.
cutoff_length is the length below which no penalisation on pipe length is applied, allowing massive throughputs in sufficiently small areas. The cutoff_length could be 250, but in my opinion should even be a bit lower since the penalty of going above is much less severe. pipe_length is the length of the pipe, either measured by the dimensions of its bounding box or the actual pipe length, whatever the devs prefer.

In essence, this allows the player to make massive pipe networks without pumps for super low throughput applications (flamethrowers, lubricant for belts, first pipe to oil...). It also gives players more design options on how to handle fluids. You can either repeat a pump every so often to keep fluids running or make a massive pump array at the beginning and/or end to get fluids through. Note that you need as many pumps in both cases to achieve the same throughput by design, making both designs viable (can be tinkered with if it upsets the balance with trains too much).

Regarding player feedback, I suggest the following options:

• If you click a pipe/pump, you get the fluid level and throughput (in percentage). Ideally, with a tooltip explaining why a percentage may be below 100%.
• In the pipe visualisation (which is great!) you could add an icon on throughput limited pipes that are colour coded to reflect how bad the throughput limitation is and some more detailed explanation if you hover over it.
• Certainly do not keep the current always on notification, as pipes may be throughput limited by design (in contrast to cut-off pipes)

Why ?

Let me first say that I have no way of knowing whether there is a problem with the new new fluids. I think it is a clear improvement on the first fluids 2.0, which was a clear improvement on 1.1 fluids. However, some people seem jarred by the idea of a sudden collapse of a fluid system just because you add 1 single pipe. Since Raiguard said he'd tinker a bit more with the fluids in the coming weeks, I thought it may be better to share this idea before 2.0 is out. I fully agree with the criticism that only the devs and playtesters can really know whether the sudden cut-off is actually a problem.

Nevertheless, I think this idea conceptually works well with the existing mechanics without adding too much new fluff. It gives the player more freedom to do whatever they want and is easy to understand. If you double the pipe above a certain threshold, you'll halve the throughput. If you ignore a sufficient amount of physics, this feels quite reasonable in how fluids really behave: to add 1l of an incompressible fluid, you need to move all fluids that are in front, which have friction with the pipe wall that scales roughly linearly with the length of the pipe if you ignore a lot of other things.

Crucially, the player can see the interaction of fluid pressure (approximated by fluid level) and pipe length easily through the proposed feedback mechanics. In my opinion, this system is roughly on par with the new new fluids on how well bottlenecks can be communicated. At the same time, it is a much more intuitive mechanic in the first place for players who are unaware of the underlying fluid system. Furthermore, the proposed mechanic does not suffer from unobvious black box magic in the way 1.1 fluids did, while it does keep some of the intuitive mechanics from 1.1 fluids (when they worked well).

Finally, though maybe unnecessary, it allows a nice UPS optimisation, where a big array of pumps pumping from 1 fluid box to another fluid box can be handled like a single massive pump (similar to solar panels). Whether or not this optimization is premature is impossible for me to know.

Thank you to all devs for this amazing game. Note that this contribution is uniquely done from a point of passion. I'm already very happy with the current mechanics, and merely think this mechanic might make it even slightly better.

[Erichteia]

Correct me if I'm wrong, but isn't this very similar to parts of the new fluid system proposed in FFF 430 (https://www.factorio.com/blog/post/fff-430) and FFF 416 (https://www.factorio.com/blog/post/fff-416)? Specifically, the pressure limiting producers to pump fluids into a pipe and consumers pumping fluids out of the pipe based on fluid level.

[Koub]

[Koub] Merged suggestions made about modifications to what was announced : before making suggestions on how something should be changed, please wait at least that the "thing" has been released and you have actually tested it.

[Erichteia]

[Koub] Merged suggestions made about modifications to what was announced : before making suggestions on how something should be changed, please wait at least that the "thing" has been released and you have actually tested it.

Completely agree! I did my best phrasing it in a ‘here is another way you might achieve a nice system that works on top of your amazing work, do with it whatever you want’. My apologies if my post didn’t reflect that sentiment

[meganothing]

I am also in favour of a more gradual decrease in pipe throughput. A gradual decrease provides an optimization puzzle where a pipe network may not have maximum throughput but still more than is needed, that is for the player to find out in each case.
A cut-off like now on the other hand only adds a necessity to add pumps sometimes without any options or choices.

And I would hope for a much much smaller bounding box, whether cut-off or gradual decrease. At the moment the limit is largely irrelevant, judging by the rather compact size a single factory has in my games.