Friday Facts #430 - Drowning in Fluids

[adam_bise]

Oh what? Oh what? Will Tomorrow's FFF be? Oh what? Oh what will it be?

From Fulgora's rain to a new toy train, Oh what? Oh what will it be?

[SirSmuggler]

Oh what? Oh what? Will Tomorrow's FFF be? Oh what? Oh what will it be?

From Fulgora's rain to a new toy train, Oh what? Oh what will it be?

Something that endlesly discussed can be, something to split the commun-ity?

[Moosfet]

If you don't want pipelines to be used so much, make them not the cheapest thing to build in the whole game. They cost 1 ore per tile to build and have 0 operating cost, so it's no surprise that you're using them so much. I think it would be better to increase the cost than to add some totally unrealistic defect to them.

Maybe make two tiers of pipe, one has low throughput but is cheap to build for early game. No need to have a distance limit, it'll just kind of naturally have one in that it can only feed a few boilers before it is at max capacity. So you can use it to run some lubricant across your base, but it's not getting all of the oil you need from your oil field to your base unless you run a dozen of them in parallel. The other tier has high throughput but is expensive to build, perhaps requiring two pieces of steel, a piece of concrete, and some plastic. That's not too unreasonable given that you get something with high throughput, instant delivery, and zero cost delivery, but the higher cost means that until you're looking at hundreds of trains full of fluid, the cost of building it just isn't justified until later in the game when the investment cost won't be felt so much, and by then you'll already have a fluid train, and so the cost of the pipeline becomes even harder to justify until you're kind of reaching the point that trains aren't keeping up anyway.

As for making the pump useful, here's my thoughts (which might be how it already works for all I know):

1. Make the pipes have no capacity. If there's nothing connected to the pipe that can input fluid, nothing connected to the pipe can output fluid. This isn't too unlike real life since we generally don't allow pipes to empty. Even major oil pipelines, they fill them with oil, and then anyone who deposits oil at one end is allowed to withdraw it at the other end immediately. They don't have to wait for the fluid to travel across the continent. So maybe if you want some realism, when you add more pipe, perhaps the pipe absorbs some fluid from the pipeline and this fluid is unavailable until the pipe is deconstructed, but I think it'd also be fine if the pipe just never had to be filled.

2. Storage tanks are last to input fluids and last to output fluids. So they work like accumulators when attached to solar panels. Since pipes have no capacity themselves, if you want any storage capacity, you have to put a tank somewhere, otherwise you need an entity wanting to input a fluid and an entity wanting to output it simultaneously.

3. Pumps are the opposite of storage tanks. They get input priority and output priority, and of course are one-way valves and don't work without power, but otherwise they're just smaller storage tanks that have input and output priority.

So...

1. If you want a storage tank to fill before machines get filled, you fill it with a pump, since the pump gets to input fluids first.
2. If you want a storage tank to empty before machines empty, you empty it with a pump, since the pump gets to output fluids first.
3. If you want a machine to have output priority, connect it via a pump.
4. If you want a machine to have input priority, connect it via a pump.

That and trains seem like enough uses for pumps to me. It's main use always has been as a valve and a train transfer tool in my opinion. I used it on long pipes too but I didn't see that as a feature, it was just making up for the fact that the fluid simulation wasn't really a good representation of how pipelines actually work. In reality, they're always full, and generally moving at a constant speed because momentum would cause high pressures that burst or crush the pipe if the speed changes too quickly. ...which can be the excuse for why they need to cost so much to build if you want high speed transfers, as they need to be extra reinforced and quick changes in transfer speed are unavoidable in Factorio, so your options are to either build something incredibly strong or to transfer your fluids slowly.

[FuryoftheStars]

No surprise that the new 2.0 was too powerful. Lot of us called that when first announced.

While I like the fact that you're trying to cut that, an arbitrary 250x250 grid is not something that's going to be intuitive or visible to a player. Especially with an all or nothing system (this just makes it worse, imo). And adding some indicator at the exact spot where a pump needs to be placed does not make it more engaging. The game is literally holding your hand, here.

In my opinion, of course:

• I think the flow rate should gradually decrease, not on/off, but never actually reach zero.
• If you aren't willing to do an actual count from last input machine type system, then a total count of pipes in the fluid segment would be the way to go.
• It should probably be less than 250 pipe segments. Starting at something smaller and increasing as needed for balance and feel is less breaking than starting at something too big.
• Undergrounds should count for their actual number of tiles covered when placed.

Still not a fan of this overall approach and wish you all hadn't just thrown the baby out with the bath water with 2.0.

Oh, and F aligning this to 256 grid if it stays as is.

--------------------------------------------------------

... and yet we still never discuss how doing the same with electricity should ABSOLUTELY be seen as a problem, for the exact same reasons. It is quite unfair and dishonest to argue one without supporting the other.

Eh, it's a little different. The more detailed fluid system was already in place but they're deciding to remove it. The arguments are against that.

A discussion about making electricity more like fluid, while I would support, is a slightly different animal.

--------------------------------------------------------

I think a lot of commenters are conflating realism with good game design and I would argue against that. If I wanted realism, I’d get a job as a process engineer.

I think a lot of people conflate the dislike of this design as wanting realism, while I don't think many actually presented it this way. I don't want system to be realistic necessarily, and I don't even care that 1.1 is not realistic either, but I just don't like the ideas as shown. Feels like they thrown away old system, and replaced it with a simplistic design of "let's just make pipe network an instant teleport system" and when it (what a surprise) turned out to be too simplistic slapped on top of it an arbitrary limitation that doesn't make much sense.

Agreed.

--------------------------------------------------------

did you forget that electric poles don’t match the tiling grid?

Big electric poles are being changed to match the grid / extended to have 32 tiles of range. They mentioned that way back with the rail changes in https://factorio.com/blog/post/fff-377

Unless they backtracked this change somewhere along the line, then ill eat my words.

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.

They made this change because of the new rail curvature radius, not because they were actually trying to align it to the grid. It just happened to work out that way.

Speaking of which, the bigger curve radius means that with 4 tiles in between directions, now the minimal convenient blueprint module size is 32x32 tiles.
We have increased the big electric pole range to 32 to go along with this.

https://factorio.com/blog/post/fff-377

--------------------------------------------------------

I just wanna say LOL at all the people who are crying over this new system and now defending the old system. "It's a little quirky but can be managed."

The old system literally doesn't work. Random machines get starved. Pipes randomly stop flowing. And they're sensitive to placement order? No thanks. I'll take 100 consistent rules over the RNG of the old system any day.

I don't know how I played with old system for 2000 hours when it "literally didn't work" then. And besides, yes, old system isn't great, but this is just not better. Old system had quirks, this one has arbitrary limits because reasons. One step forward, two steps back.

QFT

--------------------------------------------------------

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?

I think this was during either 0.16 or 0.17. I remember when they used to move differently on the corners and I started playing on 0.15's release.

--------------------------------------------------------

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".

I just gotta keep quoting you for agreement in what you're saying.

--------------------------------------------------------

Having read FFF #416 Fluids 2.0 again and this FFF, I'm wondering what items exactly will be included in the fluid segment abstraction? According to FFF #416, just 'Pipes, underground pipes, and storage tanks are merged into fluid "segments".' However, there are items such as boilers, heat exchangers, steam engines, steam turbines, flamethrower turrets and mining drills on uranium ore who passthrough fluid to their other side for convenience. Are these passthrough "pipes" included in one segment, so all tiled items are actually on the same segment, or are they segment borders and create another segment on their other side?

That's relevant for throughput, because if these machines are segment dividers, just a maximum flow of 6000/s from one machine to the next is possible and it takes time for fluid to get from the start to the end of a tiled setup just like with the 1.1 fluid system.

It's also relevant for huge border defense walls with flamethrower turrets. If the flamethrower turret is a segment divider, existing flame thrower border defense blueprints can stay as they are. However, if they're becoming all part of one big segment, the defense blueprints need to change to include oil handover from one 250-tile segment to the next.

I think each pipe segment boundary entity counts as it's own separate pipe segment. So 10 turbines or uranium mining drills all connected to each other are 10 separate pipe segments.

[furylaunch]

Please consider what the actual gameplay change is between requiring two pumps as ingredients for a batch of 250 pipes versus this... there's few interesting optimization problems, greatly expanded design choices, etc.
It's purely a resource sink and is a lot less interactive imo than the previous 2.0 model of unlimited fluids in the sense that there's no new challenge, just hassle to click on an alert and place down a pump and maybe electrical poles.
This feels like a very big mistake. Changing mechanics so soon before launch, based on one large session of public playtesting plus some limited internal playtesting, seems inadvisable; you guys had lots of internal playtesting to review the 2.0 fluids on top of the public playtest, and still took that much to figure out that the pipe mechanics were driving undesirable behavior... this change seems like it's going to have mechanical changes with even less time to cook and search for issues.
People have already laid out a few ways that the 250 pipe limit is unintuitive and is far less mechanically interesting than the old fluids, but I want to point something out as well. Right now, with just the "unlimited fluids", we'd have the optimal design as an infinite length pipeline. With these changes, the optimal design is now an infinite length pipeline with pumps every 250 units. This isn't a good change, it's just going to be busywork/unintuitive hassle for new and old players alike. I reiterate, nothing is going to change design-wise for the "fluid bus" issues mentioned, and the blocker for megabases doing designs with this isn't going to be the actual designing or management of pipes, it's going to be making sure your design tiles correctly.
Please consider the impact this is going to have on early/midgame bases - building a fluid design and then seeing a jarring popup telling players they need pumps. Please consider the impact this is going to have on lategame megabases - troubleshooting a fluid design and noticing that they stamped one of their blueprints down too close or too far, and now they need two sets of pumps, or what have you.
This isn't going to make pipelines any less viable, just far more annoying.
Also, the best way to make "boring" pipelines less of an obvious choice is with trains being a better choice. I don't see why we're nerfing pumps; the argument that "oh, well if you get high quality on all your stuff then it goes back to how it was before" seems irrational to me, because by the time players have quality to waste getting pumps back up to 1.1 speed, they're way out of the early/midgame. So they're disincentivized from using trains for the early parts of the game that the most players are going to go through, and would just be hassled by a resource check of "you need 1 pump for 250 pipes"? How does this make players less likely to make large pipelines?

[mmmPI]

The amount of people not realizing that :

The previous system was already very good at showing limitation of throughput decreasing gradually over distance, many of the proposition to remake something similar seem to me "worse" version than the previous system. ( yes the "old system had some quirks, but many of the proposals do not seem to integrate what caused those, and seem likely to also have the same problems of update order difficult to understand when missing fluid or not using pumps.)

I don't think the "new" presented system with the 250x250 limit is perfect. But i think it shows a direction on which to improve and build maybe for it to be more visible in game what is a 250x250 area that has 1 fluid network, where does it start and begins ? the boundaries , is it moving when you remove pipe at an extremities and so on, rather than trying to "sell the old-as-new". I think trying to advise "make the new more like the old" is not going to yield feedback that would be as valuable as : "how to make the new one more enjoyable".

I think the limitation on pump throughput will add back a little of the calculation and planning that would/could have been removed with unlimited pipes without the 250x250 limit. Even if it may sound arbitrary, i think it could lead to good gameplay situation if players are able to plan around them. It will hopefully stop people who put pumps everywhere mindlessly to do so, and create situation where you need to think wether or not you need pumps in a place or if you could do without it in order to keep the fluid flow "unlimited".

[picklock]

I think it's very good that problems with the flow of liquids are now visualized in the game. As someone who has been playing for a long time, I have to get used to the restrictions due to the pipeline length and the balancing adjustments. Let's see what else is in store for us after 2.0.

[Goodman599]

As a guy who doesn’t really dive that deep into the mechanics of factorio, I like the new fluid system more. The old one just didn’t work sometimes, and I would have no idea why. This one, while being unintuitive, is at least easy to understand. But honestly, fluid dynamics as a whole have so many intricacies that aren’t visualized (like machines taking 6000/s input max, I literally never knew that before this fff) that I hope there’s a small tutorial for those like me who need it.
Why is a tutorial necessary? Because I think space age will be an entry for a lot of players like me to build their first mega base. In base factorio, there’s no real incentive to building a mega base other than “big number good.” So I’m sure lots of people don’t play that much after the first few rockets. That’s why teaching these players the fluid system and how to best utilize it is important.

In contrast, belts are so much easier to understand. Even quirks like side loading (a feature that doesn’t exist in many other games) make a lot of sense, just by looking at it.

[CometVoid]

Why not have channels/aquaducts?

They'd help with fluid visualization greatly, and could work just like belts with them being directional (pumps wouldn't really make sense), and i bet channels of glowing liquids would look really pretty at night!

Of course, pipes would still need to exist for things like steam, but a pressurized pipe system could work side by side with a slower, but simpler and much cheaper duct system.

[Junorus]

No surprise that the new 2.0 was too powerful. Lot of us called that when first announced.

While I like the fact that you're trying to cut that, an arbitrary 250x250 grid is not something that's going to be intuitive or visible to a player. Especially with an all or nothing system (this just makes it worse, imo). And adding some indicator at the exact spot where a pump needs to be placed does not make it more engaging. The game is literally holding your hand, here.

In my opinion, of course:

• I think the flow rate should gradually decrease, not on/off, but never actually reach zero.
• If you aren't willing to do an actual count from last input machine type system, then a total count of pipes in the fluid segment would be the way to go.
• It should probably be less than 250 pipe segments. Starting at something smaller and increasing as needed for balance and feel is less breaking than starting at something too big.
• Undergrounds should count for their actual number of tiles covered when placed.

Still not a fan of this overall approach and wish you all hadn't just thrown the baby out with the bath water with 2.0.

Oh, and F aligning this to 256 grid if it stays as is.

I hate arbitrary limits as well.
It would be enough to have pipeline segment flow rate scale like n^-2 of pipes and then tanks and pipes being separate segments (this all could still lead to tank-lines being highest flow rate...). No infinite transfer and bigger is slower.

Or if straight lines of pipes have common volume. So if you make a turn at any place it is another segment and there is flowrate between them...

[3-Valdion]

A "relatively" small rework of the 2.0 pipelines and pumps to make them feel more natural.

When I read the FFFs about how fluids changed in 2.0, I was glad to hear that the system would be shifted to a new, less computationally demanding system that would also allow fluids to move at a much faster rate within pipelines. Not so surprisingly, however, it turned out that removing the throughput limits had... Adverse effects on gameplay. So, a patch was implemented after the LAN playtest to make pipelines unable to be made over 250 long, at least without pumps, and pumps were also nerfed greatly to limit throughput. Admittedly, being able to pump 1200 units of fluid a second no matter the distance (well, under 250 tiles at least) is still way better than what it used to be (about 13 pipes before needing to place a pump, if I remember correctly) but it feels... Wrong, and somewhat artificial.

I want to make this clear, 2.0 pipelines do seem MUCH better to work with and more reliable from the FFFs and Hendrick's stream but not quite there yet which is what prompted me to think of better ways to do pipes, which I will now get to and stop turning around the pot :

Instead of having pipelines have a fixed, hard limit on length which can get in the way for low throughput pipelines (such as a far away oil field making less than 500 units of oil per second) I don't think there should be any need for a pump. So, then I started thinking : why should there be a hard limit on length, instead of a soft one?

I'm pulling these numbers out of my *ss here, because I've got no idea what they actually are in 2.0, but here we go :

Say a pump (or a building) can move 50 000 units of fluid per second. Now you connect it to pipelines, and it start dropping exponentially but never reaches zero (I can't find the name of the function, but it's not the logarithmic one - at least I think) and reaches 5 000 units of throughput at around 250 pipelines long (maybe more or less, depending on balancing). You can make it as long as you want, but it'll be severily limited by throughput as you make it longer. If you want to keep high throughput, you could put down a few pumps - but they wouldn't limit throughput, simply "reset" the pipe length so it can go on for another few hundred pipes with the throughput you want. However, for balancing reasons, I think pump power consumption should increase as per a square root function depending on the length of the pipeline segment, to "combat friction" but would eventually be hardcapped when the throughput reaches a low enough value, such as 100 units a second for example.

This raises another issue, and a QOL feature that 2.0 brought with the new pipeline system. Currently as per what I saw in Hendrick's stream it is CLEARLY defined when a pipeline "breaks". However, if my suggestion is implemented, you'd never know if a pipeline is too long and becomes a bottleneck, which from what I understand, is why the hardcap was implemented in the first place. So to fix it, I think a relatively simple solution (I'm not a programmer, please spare me) would be to have the exact same warning system activate when the pipeline is fully capped at max throughput for some time, say five minutes (if it's too short, then the alarm maight activate from a burst of production, for example). I am not talking about the FULNESS of the pipe, but it's throughput. If you have a pipe that's capped for some time, then it's almost certain it just doesn't have enough throughput. In Hendrick's stream, I also noticed that it told you how long the pipeline was - and that should stay in, but it should also tell you in game what the maximum throughput of the pipeline is, as well as its current throughput. This way, it would still be really easy to tell what's going wrong.

As for why I think this should be in the game, well... Sometimes, you really just want to make a stupidly long pipeline and don't care AT ALL about its throughput. Like when Dosh went to the edge of the world and had the flamethrowers fed by super long pipelines, that would be now broken. Also I think this way of doing it feels a lot more like a fluid, the hard cap at 250 pipelines genuinelly feels wrong to me.

[Nova]

Sometimes, you really just want to make a stupidly long pipeline and don't care AT ALL about its throughput. Like when Dosh went to the edge of the world and had the flamethrowers fed by super long pipelines, that would be now broken.

No, Dosh did use pumps there.

[3-Valdion]

Ah, good to know. Well it makes sense, but I do believe they were spaced REALLY far appart, way more than 250 so my point still stands.

[jackthesmack]

This new fluid system of 250 size limit is actually amazing, because it could potentially be applied to power grids. Have a high voltage and medium voltage power system. High voltage has infinite range, but medium voltage has a limited grid size just like the new fluid, and connects to the high voltage grid. All machines would use the medium voltage.

It gets super messy and restricted if you try to have different voltages for different machines, like lights using low voltage, because then your setup because a convoluted mess of powerlines. Medium and High voltage splits your grid sections which would be pretty neat to handle, without being overly complicated.