Factorio Forums

Dominik wrote: Mon Sep 16, 2019 12:14 pm

bman212121 wrote: Sat Sep 14, 2019 3:34 pm 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.

HurkWurk wrote: Thu Sep 19, 2019 5:30 pm

DaleStan wrote: Thu Sep 19, 2019 4:36 pm 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)

bman212121 wrote: Sat Sep 28, 2019 9:57 pm

Dominik wrote: Mon Sep 16, 2019 12:14 pm

bman212121 wrote: Sat Sep 14, 2019 3:34 pm 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.