Friday Facts #416 - Fluids 2.0

[Panzerknacker]

hopefully the new system will see less people complaining that the logic is absolutly flawed because it's easier to use
and that everyone will be able to finally use pumps to control where the fluid goes

I wonder why someone would assume that people don't use pumps now? Given that there are untold numbers of publicly available screenshots of pumps being used by veterans and newcomers alike.

I am basing this on quotation like this one where you clearly stated you can't use pump to control the fluid :

viewtopic.php?p=609354#p609354

Even increasing the number of pumps and fluid throughput continues to demonstrate that I cannot control where the fluid goes in the same way a splitter can control where items go with priorities and filters.

I know there are untold numbers of available screenshots of pumps being properly used by veterans and newcomers alike. But occasionnaly there was a player that couldn't manage to do so and blame the game, like you and some others did in the post i quoted. I hope this is going to change with the system now made easier.

#Picard_Face_Palm_Meme

I demonstrated knowledge of how to break the fluid simulation in a manner that makes it impossible to control which machines on a branch of a junction receive fluid first to last in that thread.


Furthermore, if one reads the entire post from beginning to end. One will find this sentence, which further drives the point I was trying to arrive at.

Since the point is to demonstrate that pipe junctions are black boxes that the players have no discrete control over beyond picking up and placing pipes without knowing what they would do afterward.

The problem is how to teach players how to control the fluid in an intuitive way in the game itself.


Think about it: how could I create a demonstration of fluid simulation that doesn't work intuitively if I didn't know how the fluid simulation works?

If I were seeking a solution to the junction issue with fluid simulation, I would not debate the merit of keeping the fluid simulation by teaching it in-game to players better.

What is the point tho, if your junctions are giving 'problems' because one machine gets more fluid than the other, starving a few of them, just increase fluid production capacity, how obvious can it be from a gameplay perspective? And if you really wanna go autist about perfect ratios the problem will ALWAYS fix itself eventually, just a matter of time because if not all plants are running the pipes will keep filling up eventually untill everything works.

[mmmPI]

What is the point tho, if your junctions are giving 'problems' because one machine gets more fluid than the other, starving a few of them, just increase fluid production capacity, how obvious can it be from a gameplay perspective? And if you really wanna go autist about perfect ratios the problem will ALWAYS fix itself eventually, just a matter of time because if not all plants are running the pipes will keep filling up eventually untill everything works.

The point i think was to illustrate the inability to use circuit controlled-pump by some players, leading to a request for more tutorial in game. Because just changing the fluid system isn't going to help the people posting on reddit that they couldn't go past blue science because of the fluid mechanic.

[sarge945]

As someone who spent many years of primary school playing Thermal Expansion, I find this new implementation extremely intuitive.

I think the biggest loss I am seeing is that it may become more efficient to run infinite length pipes than to build fluid transport trains. Not that the old system stopped me in the past so maybe nothing changes.

long pipes have the downside of biter attacks hitting them though, trains might still be better for this since Biters only attack Rails under certain circumstances.

Yeah I kind of agree with people here saying that the new pipes are essentially "teleporters", and make long pipelines super viable. I understand the need to simplify the system to make it more intuitive, but this makes it way too simple in my opinion.

Being attacked by biters isn't really a major issue since, unless your oil or water is in a super inconvenient place, most of the time it's relatively easy to defend it.

I guess a good solution would be to make connected machines pull at a slower rate if their pipeline is longer than some length, with worsening effects as the distance increases.

So after, say, 50 pipe lengths, anything plugged in on the other side would suffer from 20% throughput, decreasing by an additional 10% every 50 pipes until it stops entirely. But you can then build a pump to "reset" the limit. Any slowdown anywhere along the chain would affect any other segments, so you can't just build 1 pump at the end to fix everything.

This simulates "pressure" in an intuitive way, and disincentivises long pipelines unless you're prepared to build lots of pumps.

It might not actually be worth fixing, though, since trains are already extremely useful for transporting goods in general, so stamping down a blueprint for another station and building a fluid wagon is probably easier and less hassle if you already have a big train network set up. Not to mention it's easier to build rails to integrate new sources into your infrastructure than it is to pipe in a new source.

[XT-248]

hopefully the new system will see less people complaining that the logic is absolutly flawed because it's easier to use
and that everyone will be able to finally use pumps to control where the fluid goes

I wonder why someone would assume that people don't use pumps now? Given that there are untold numbers of publicly available screenshots of pumps being used by veterans and newcomers alike.

I am basing this on quotation like this one where you clearly stated you can't use pump to control the fluid :

viewtopic.php?p=609354#p609354

Even increasing the number of pumps and fluid throughput continues to demonstrate that I cannot control where the fluid goes in the same way a splitter can control where items go with priorities and filters.

I know there are untold numbers of available screenshots of pumps being properly used by veterans and newcomers alike. But occasionnaly there was a player that couldn't manage to do so and blame the game, like you and some others did in the post i quoted. I hope this is going to change with the system now made easier.

#Picard_Face_Palm_Meme

I demonstrated knowledge of how to break the fluid simulation in a manner that makes it impossible to control which machines on a branch of a junction receive fluid first to last in that thread.


Furthermore, if one reads the entire post from beginning to end. One will find this sentence, which further drives the point I was trying to arrive at.

Since the point is to demonstrate that pipe junctions are black boxes that the players have no discrete control over beyond picking up and placing pipes without knowing what they would do afterward.

The problem is how to teach players how to control the fluid in an intuitive way in the game itself.


Think about it: how could I create a demonstration of fluid simulation that doesn't work intuitively if I didn't know how the fluid simulation works?

If I were seeking a solution to the junction issue with fluid simulation, I would not debate the merit of keeping the fluid simulation by teaching it in-game to players better.

What is the point tho, if your junctions are giving 'problems' because one machine gets more fluid than the other, starving a few of them, just increase fluid production capacity, how obvious can it be from a gameplay perspective? And if you really wanna go autist about perfect ratios the problem will ALWAYS fix itself eventually, just a matter of time because if not all plants are running the pipes will keep filling up eventually untill everything works.

You missed the point.


The problem is teaching new people how 'junctions' in Factorio 1.1.x don't equally distribute fluids among different paths, instead, the prioritization is based on which pipes were built first. Also, Players can maximize the fluid input as much as they want into a junction, but the problem remains in the background. We were talking about Fluid Simulation from Factorio 1.1.x, which does NOT have unlimited throughput.

When I have fluid (using water as an example here) starved for ANY reason whatsoever, I might want to prioritize fluid (water) flows to nuclear energy or critical infrastructure over non-essential concrete or explosive production chains.


The way I understand the removal of fluid simulation negation some of the issues but not entirely since ALL machines draw fluid from the same pipe network equally without giving players any control without requiring multiple pumps/circuits/etc., which is essentially the same problem we had with Fluid SImulation 1.1.x from before except the issue is affecting the entire network at once instead at a single point (pipe junction).

Given the new fluid simulation-less mechanics, the pipe network has no built-in prioritization control and prioritization that works without external power sources (in case something goes wrong).


Also, please don't accuse other people of having a mental condition, fictional or otherwise, to make a point. I would appreciate what someone has to say more without the personal commentary.

[mmmPI]

When I have fluid (using water as an example here) starved for ANY reason whatsoever, I might want to prioritize fluid (water) flows to nuclear energy or critical infrastructure over non-essential concrete or explosive production chains.

You could easily achieve that with pumps in the old and new system though.

[XT-248]

When I have fluid (using water as an example here) starved for ANY reason whatsoever, I might want to prioritize fluid (water) flows to nuclear energy or critical infrastructure over non-essential concrete or explosive production chains.

You could easily achieve that with pumps in the old and new system though.

Does the pump work without power yes or no?


We already covered this in a prior conversation.

[mmmPI]

No the pump require power, therefore if you gate your non-essential stuff behind one, during low power, the water will only be allowed to flow toward the nuclear energy or critical infrastructure, making it very easy to do.

It's easier than the previous case we discussed where pumps were used to prioritize fluid in different assembly, (things that are still valid for the new system ).

[DrentalBot]

so, with the blog 420 out now - we can see some new piping challenges with coolant in highly constrained spaces (powering a space platform means every tile is important)

how do you feel about that as a piping challenge in exchange for flow challenges?

[The Phoenixian]

I'm curious whether the new fluid system would allow temperature chain recipes, a la pre-2017 boilers.

I know nothing in the game uses it now, and it wouldn't surprise me if changes to the engine even before this made it outright impossible, but it is something I'm nostalgic for, as one of the people who wanted to use that kind of system for fluid-to-fluid heat exchange back in the day.

[XT-248]

No the pump require power, therefore if you gate your non-essential stuff behind one, during low power, the water will only be allowed to flow toward the nuclear energy or critical infrastructure, making it very easy to do.

It's easier than the previous case we discussed where pumps were used to prioritize fluid in different assembly, (things that are still valid for the new system ).

Instead of going back and forth on this subject, I will present a problem with limitations on how to solve it. It may get everyone on the same page and end this side-conversation that has been going on for months.


The objective is to take four unmodified pumps and four storage tanks and devise a prioritization control pipe junction that can be accommodated in a smaller area than nine-tile-by-nine-tile. Currently, the best I can achieve is approximately nine-tile-by-nine-tile. The ten-tile-by-nine-tile configuration, as shown below, is a result of my preference for symmetric power connections (hint: move the solar panel one tile west and the power pole further closer to the center).

Pipe Junction Examples.png (224.63 KiB) Viewed 1967 times

As anyone can see, the outgoing valves, the bottom portion of the screenshot, work without power and fit in a five-tile-by-five-tile area with plenty of room for other objects, including logic circuits, to monitor the fluid level. Not pictured, but it can be done in a six-tile-by-six-tile area (one tile longer on both sides for adding a single solar panel).



Now, I will list limitations on which to make a prioritization junction alternative designs.

1) If any entities within the prioritization control junction consume power, the power network should have sufficient energy storage, such as accumulators, if it cannot run continuously.

2) Purple pipes are editor entities used to denominate where the input and outputs are and can be used on different sides of the storage tank. Underground/above-ground-pipe are okay to use instead. Input/output pipe sections count toward space limitation.

3) A prioritization junction must have a set of four logic-deciders or logic-arithmetic and four storage-tank-to-check-the-fluid-level to control fluid flow (it doesn't matter if it is incoming or outgoing).

4) All four branches of a prioritization junction can only cross to another branch by going through two pumps (the first time for the input pump and the second time for the output pump). IE: The "IN" branch can not cross to "1" or "3" branches before going through two pumps.

P.S. Constant combinator does not count toward the space limitation as it shows which pipe is which.



Opening the input and one of the outgoing branches to have no pump to allow fluid to flow unchecked breaks the following limitations: #3 (logic to control and fluid monitor on all junction branches) and #4 (needs to have two pumps at a minimum). Technically, limitation #1 was also broken since the existing non-working pump without power was supposed to have backup power.

[mmmPI]

Currently, the best I can achieve is approximately nine-tile-by-nine-tile.

That's very impressive !

I don't think this is going back and forth, and i feel like you learned a lot since that earlier quote :

Even increasing the number of pumps and fluid throughput continues to demonstrate that I cannot control where the fluid goes in the same way a splitter can control where items go with priorities and filters.

Now, I will list limitations on which to make a prioritization junction alternative designs.

That remind me of a challenge where the definition of the rules kept changing over the course of it due them being very badly defined in the first place and getting worse over time x). I think i'm going to skip this one for now and see if other players can use the fluid system as well as you do, and maybe learn a few trick or two if someone manage to understand the rules/purposed of the challenge.

I think you forgot that you can put fluid into barrel, if you want to control fluid with splitters. No sure if that is part of the rules as it's a way to solve the problem or if it doesn't count because it's a made up challenge to proove the problem can't be solved.

[XT-248]

That's very impressive !

I don't think this is going back and forth, and i feel like you learned a lot since that earlier quote :

I have not learned anything new in the past few months that I did not already know from years ago.

I think you forgot that you can put fluid into barrel, if you want to control fluid with splitters. No sure if that is part of the rules as it's a way to solve the problem or if it doesn't count because it's a made up challenge to proove the problem can't be solved.

Adding assemblers, chests (to monitor how much fluid there is), inserters, splitters, a higher power demand (read more solar panels and possibly a few accumulators), and other objects, and adding all of those up together requires more space than available in a small compact area. This illustrates a narrow understanding of what I am trying to communicate here.

That remind me of a challenge where the definition of the rules kept changing over the course of it due them being very badly defined in the first place and getting worse over time x). I think i'm going to skip this one for now and see if other players can use the fluid system as well as you do, and maybe learn a few trick or two if someone manage to understand the rules/purposed of the challenge.

The goal is to keep the prioritization junction infrastructure small/compact and 100% functional through blackout. This has not changed.

I just refined the issue/content in a way that is easier for others to understand.

[mmmPI]

I have not learned anything new in the past few months that I did not already know from years ago.

my bad sorry, i was mistaken.

I just refined the issue/content in a way that is easier for others to understand.

It help me too thanks

[DarkShadow44]

What happened to the fluid system planned in FFF 260 and FFF 274?

FFF 260 spoke about a few issues with the "radical approach":

However we have decided not to pursue this, for a few reasons.
There would be no visualisation or indication of the flow of fluid.
There would be unlimited throughput, one water pipe could supply all boiler and reactor setups.
It abstracts away part of the realism and charm of the game. (While this is subjective at best, it does mean something to us.)

I think I will miss the realism of actual flow and having do deal with throughput issues, infinite throughput just doesn't seem right to me. I get that the old system was unintuitive, but I thought the planned rework would fix the issues with the old fluid system while avoiding those issues... Did something change that you decided to throw away flow altogether?

[meganothing]

A friend of mine had the idea that each single pipe in a network could waste a small fixed amount of fluid. Not sure if the idea came up already,

That would simply mean keeping a counter of how many pipes are in a segment and deducting that number times a constant value each tick before anything gets supplied. As a result far away drains would still get supplied the same as near drains, but longer pipe networks would initially take more time before any drain gets supplied and the maximal throughput of long pipe networks would only be a percentage of a small pipe network

This would make long pipes inefficient and supply by train more efficient.

[aka13]

A friend of mine had the idea that each single pipe in a network could waste a small fixed amount of fluid. Not sure if the idea came up already,

That would simply mean keeping a counter of how many pipes are in a segment and deducting that number times a constant value each tick before anything gets supplied. As a result far away drains would still get supplied the same as near drains, but longer pipe networks would initially take more time before any drain gets supplied and the maximal throughput of long pipe networks would only be a percentage of a small pipe network

This would make long pipes inefficient and supply by train more efficient.

I think that high maintenance-mechanics, like bot repair, lubricant to assemblers, random repair tasks and item voiding are not fun at all. Like I could never enjoy a game centered around constant busywork upkeep, but obviously, not everyone is like that - a lot of people enjoy don't starve, for example.

[meganothing]

A friend of mine had the idea that each single pipe in a network could waste a small fixed amount of fluid. Not sure if the idea came up already,

That would simply mean keeping a counter of how many pipes are in a segment and deducting that number times a constant value each tick before anything gets supplied. As a result far away drains would still get supplied the same as near drains, but longer pipe networks would initially take more time before any drain gets supplied and the maximal throughput of long pipe networks would only be a percentage of a small pipe network

This would make long pipes inefficient and supply by train more efficient.

I think that high maintenance-mechanics, like bot repair, lubricant to assemblers, random repair tasks and item voiding are not fun at all. Like I could never enjoy a game centered around constant busywork upkeep, but obviously, not everyone is like that - a lot of people enjoy don't starve, for example.

Maybe there is a misunderstanding, the waste would be deducted for fluids leaving a segment, not some fluid that is sitting there in storage. Only "transport" would waste some percentage.

If that wasn't your concern, what is it? I don't see anything else that would make this similar to bot repair, ....

[GregoriusT]

That would give too much incentive to just have direct insert factories but for fluids, not to mention the loss inside the pipes would be hard to calculate, and not just correspond to the pipe itself but also to whichever recipe is being processed, because the number of fluid that the Recipe consumes would matter for this particular Maths.

[Yodo]

I know the answer is probably no, but is there any way that the 1.1 fluid system can be kept in the game so that mods such as Fluidic Power can keep working? As a legacy option, only accessible by mods.

[mrvn]

> Longer pipelines have higher throughput, but take longer to fully empty.

Does that mean that if I put a bunch of tanks on the side of my pipeline the throughput increases?

A tank is just a pipe with larger volume. So a tank just increases the buffer capacity of the segment, not the flow rate. From the description it only matters what the factory is connected to, not what else is in the segment. If a chemical plant is connected to a pipe then it can't put more than 100 fluid into that pipe. And for taking out it can take no more than a share of the pipes fluid level.

That said connecting factories to tanks should help. Taking 10% of 100 units in a pipe is far less than 10% of 25000 units in a tank.

In fact from what was said (pumps having an exception with tanks as well) it sounds like every pipeline should start and end with a tank. Anything you put into the tank at the start instantly appears in the tank at the end as well. More specifically the level balances instantly. Right?