Friday Facts #312 - Fluid mixing saga & Landfill terrain

[BlueTemplar]

It's likely that the (IMHO) most aggravating of the fluid "mixing" issues - not being able to completely purge a fluid network using pumps because the closest pipes ended up with 0 fluid - and therefore no "pull" - sooner than the farthest - has been solved in 0.17 by the enforced deletion of the "remaining drops" (which means that you lose ingredients and therefore can also lose "perfect ratios", but you can't have your fluids and drink them too...)

And so, with this issue fixed, and now being able to easily repair the mistakes that we might have made, the - introduced at the same time - fluid mixing touching prevention strikes me to be a regression (especially in a mod setting, where Picker Pipe Tools is available, and the prevention messes with Picker Dollies and such...)

[bman212121]

Snip

I don't understand why you would want to ignore the one thing that makes items and fluid different, that is that fluid can be split into any amount. Fluid does not come in boxes so why treat it that way? People can use barrels if they want that.
It would not be intuitive and look silly in some cases. A "box" of fluid arrives to a junction. What does it do?

From the code perspective there is this small word with big implications - in no. 8 - a factory "pulls" the fluid. How would you model the vacuum/pulling? I think that you would end up with the same thing we have now.

I wasn't expecting anyone to really look at this, but I'll try to expand a bit more. I don't want to split fluids into sizes smaller than integers. You don't consume fluids in smaller portions than that so there is really no need to have them become fractional entities that require complex calculations. Using a barrel isn't really the same thing because you are still using different sized amounts of fluids all of the time, so it's not like you are always moving the same amounts. The main thing is rather than it having a super complex model, it is just a basic thing that can actually be calculated with a spreadsheet.

Yes pulling would mean to basically determine what is available in the tile adjacent to it, and consume what it can. So an example could potentially be I need 2 water on a tick, and there is 2 water in the pipe. I moved that two water in the pipe forward, and iterate that same 2 water down the pipe all the way back to a source. I totally agree that creating the movement is still going to be problematic as soon as you hit a junction, don't have enough fluid to satisfy the request, etc. The main thing is to just make you the model isn't trying to cause massive amount of rounding and ever growing fractions. When you have a splitter on a belt, it pulls from one side, then from the other. I'd rather see fluids do that then start cutting the numbers into 1/2, then 1/4, then 1/8, etc. Ideally the model would just move x number of items all the way through the pipe. So if I consume 2 water, then it needs to move 2 water from the next pipe section. If there is only 1 water, then move 1 water and 1 air. If there is no air in the pipe then only move 1 water. So the model would be that the pipe is always "full" but it might be full of units of air. When you get to a junction use the same logic of a splitter where it simply takes turns going back and forth. The idea though is to always move x number of items based upon how many were requested. If there is available space in the pipe, the thing consuming can pull additional fluids through it. If there is not then something needs to obviously move or it will stop production. When you iterate the 2 water back to a source, if there is the ability of the source of providing 2 units, it will do so. Obviously that could get complex if there are many sources to choose from. The main point is rather than continually splitting the item into ever smaller bits each time it moves forward you're moving forward as many units as what was requested. How to actually code something like that? Not really sure, just throwing out a base idea to build upon of some way you can build a model that could be calculated and players could see what's going on with it.

Is any of that realistic? Nope, not even close. The point is that fluids as a complex realistic simulation really isn't fun. I've been playing this game since .12, and have dealt with the frustration of fluids since then. Weird things happen, and you can't really explain why some pipes work, and others do not. I've put down long pipe runs, and they just stop working at some point. That's not the case with belts, that's not the case with power. With belts there is an obvious visual feedback to where you can clearly see the problem. You don't get that feedback with pipes. Toss in a pump, and it will just add to the unpredictability of what it's going to do. Fluids in their current state are incredibly complex, and it seems to detract from the game more than it adds to it. No one is going to be able to build fluid simulation models in an Excel spreadsheet, so understanding what's going isn't realistic for most players. So it's back to just brute force a bunch of stuff, place it on the map, and hope that it stays working. Any ratios that I know at this point are based upon trial and error rather than actually being able to calculate it ahead of time. I would gladly trade realism for the ability to calculate what's going on in an easy fashion.

[mrvn]

So that means that that in this case, the two outside (built) underground pipes would be connected, even though they should have different content. Is that what you meant to do?

the answer is no. let me walk through what i invision.

1. you have your setup you picture. no pipes are connected to both ends of the existing underground pipes so the existing underground pipe contains nothing and is not tagged yet.

2. ghosts still count. so even if you maliciously (in the example you posted) connected those outside undergrounds to existing pipe networks, they would not carry fluid because the ghosts between them exist. in short, they are still waiting. (for the ghosts to be connected)

3. if instead, you built the outside pipes first, then let them populate (ie the pipe currently contains water for example) the minute you place the ghosts, the underground pipe is split by the ghosts, causing them to destroy their current content and go to a waiting state. while in that waiting state to go from ghost to real, you would disallow actions that would create mixing. IE dont tag ghosts, and instead check on attempted placement. if it were construction bots, it would hover over the pipe with that invalid placement warning, if it were the player, when you try to place it would give you the fluid mixing warning, because at construction time is when we would check, not at ghost creation.


to list the changes im describing as I see them (no idea if this is accurate)

1. underground pipe segments do not activate (activation meaning check for a fluid type to bind to) until 2 real underground segments are built, and have pipes/machines attached on both sides.
2. underground to ghost pipes trigger the above, causing the underground pipe to destroy any existing content when a ghost is placed between active underground pipe segments.
3. removing a ghost triggers the building test. the pipe should detect that the "new" connection would cause fluid mixing and go to a yellow exclamation warning state waiting for the players attention to remove and rebuild things, but not allowing the underground pipe to complete its connection. This means that if you mess around and create an accidental mix by overlaying ghosts, etc, that the underground segment needs new code to go to that error state instead of just passing fluid.

almost forgot.
for PvP, i would change the rules and make it so each team had its own pipe network and that they would not connect. This would obviously require code to change pipes from different teams to behave differently, and i would also tint pipes by team. (assuming base game no mods)

You are only looking at and solving a special and overly simplified case.

Connect a pipe to the outside underground pipes, connect a tank to that, fill the tank with fluid. Now every pipe should be tagged. Everything but the underground pipes would actually be filled since you only special case underground pipes. Connect more pipes to the outside pipes and a chemical plant. Now the pipes should also be filled and the second chemical plant working.

I don't see any point in special casing underground pipes. Any set of fluid boxes should be handled the same way. Doesn't matter if it's 2 underground pipes connecting or 2 pipes or a tank and a chemical plant. In all cases it's fluid boxes getting connected. That is either allowed or not allowed.

The problem that has to be solved is that some user actions are multiple actions in the game engine producing multiple fluid box connections to be created and destroyed. And not everything is checked properly in that case.

[Dominik]

Snip

I don't understand why you would want to ignore the one thing that makes items and fluid different, that is that fluid can be split into any amount. Fluid does not come in boxes so why treat it that way? People can use barrels if they want that.
It would not be intuitive and look silly in some cases. A "box" of fluid arrives to a junction. What does it do?

From the code perspective there is this small word with big implications - in no. 8 - a factory "pulls" the fluid. How would you model the vacuum/pulling? I think that you would end up with the same thing we have now.

I wasn't expecting anyone to really look at this, but I'll try to expand a bit more. I don't want to split fluids into sizes smaller than integers. You don't consume fluids in smaller portions than that so there is really no need to have them become fractional entities that require complex calculations. Using a barrel isn't really the same thing because you are still using different sized amounts of fluids all of the time, so it's not like you are always moving the same amounts. The main thing is rather than it having a super complex model, it is just a basic thing that can actually be calculated with a spreadsheet.

Yes pulling would mean to basically determine what is available in the tile adjacent to it, and consume what it can. So an example could potentially be I need 2 water on a tick, and there is 2 water in the pipe. I moved that two water in the pipe forward, and iterate that same 2 water down the pipe all the way back to a source. I totally agree that creating the movement is still going to be problematic as soon as you hit a junction, don't have enough fluid to satisfy the request, etc. The main thing is to just make you the model isn't trying to cause massive amount of rounding and ever growing fractions. When you have a splitter on a belt, it pulls from one side, then from the other. I'd rather see fluids do that then start cutting the numbers into 1/2, then 1/4, then 1/8, etc. Ideally the model would just move x number of items all the way through the pipe. So if I consume 2 water, then it needs to move 2 water from the next pipe section. If there is only 1 water, then move 1 water and 1 air. If there is no air in the pipe then only move 1 water. So the model would be that the pipe is always "full" but it might be full of units of air. When you get to a junction use the same logic of a splitter where it simply takes turns going back and forth. The idea though is to always move x number of items based upon how many were requested. If there is available space in the pipe, the thing consuming can pull additional fluids through it. If there is not then something needs to obviously move or it will stop production. When you iterate the 2 water back to a source, if there is the ability of the source of providing 2 units, it will do so. Obviously that could get complex if there are many sources to choose from. The main point is rather than continually splitting the item into ever smaller bits each time it moves forward you're moving forward as many units as what was requested. How to actually code something like that? Not really sure, just throwing out a base idea to build upon of some way you can build a model that could be calculated and players could see what's going on with it.

Is any of that realistic? Nope, not even close. The point is that fluids as a complex realistic simulation really isn't fun. I've been playing this game since .12, and have dealt with the frustration of fluids since then. Weird things happen, and you can't really explain why some pipes work, and others do not. I've put down long pipe runs, and they just stop working at some point. That's not the case with belts, that's not the case with power. With belts there is an obvious visual feedback to where you can clearly see the problem. You don't get that feedback with pipes. Toss in a pump, and it will just add to the unpredictability of what it's going to do. Fluids in their current state are incredibly complex, and it seems to detract from the game more than it adds to it. No one is going to be able to build fluid simulation models in an Excel spreadsheet, so understanding what's going isn't realistic for most players. So it's back to just brute force a bunch of stuff, place it on the map, and hope that it stays working. Any ratios that I know at this point are based upon trial and error rather than actually being able to calculate it ahead of time. I would gladly trade realism for the ability to calculate what's going on in an easy fashion.

Using some int units was also considered. The system is not going to change like this at this stage, it works pretty well, no reason really to change it.
Again, the word "pull". It implies doing some search through the pipes. But that is a very expensive operation and currently that is not needed.
Splitting to 1/2 etc. does not work well. What if, on a junction, left pipe is almost full and right is empty? All should go right. Etc. And similar with pulling - you are not only "pulling" from providers, but also from all the pipes anywhere that also contain fluid. In the end, pulling is quite the same as pushing, and is not as efficient as a simulation that only does local updates.

[Serenity]

Don't take this the wrong way, as I'm not saying that one game's implementation is better than another, but Oxygen Not Included does have fluids and gases as discrete units. It may not be realistic, but it works. And it's very easy to visualize what is going on. Each pipe segment can hold a certain amount. Materials can get mixed up in one pipe. If you pipe the wrong thing to some machines they get damaged. I think in some other cases if a packet can't get consumed after a junction it doesn't go that way. If no alternate path exists things get jammed up.

Some of the appeal of that doesn't work for Factorio though. For example if you make a mistake and have to deconstruct a liquid pipe the content gets dropped to the ground.