I think Pipe Networks should be Handled like a Reservior

[withers]

...the same way as electric networks are currently handled in the game.  Pumps become "providers" to the fluid pressure and equipment that uses fluids are "consumers".  Factorio treats fluids this way and it works very nice.  They define a "pressure" which affects how fast consumers are able to draw from the pipe network.  (so it's not like there'd be instant travel from one end of the pipe to the other) Heat transfers wouldn't be affected, just use the average temperature for the fluid, just like reservoirs are handled.

Benefits: 

• No confusion over which direction fluids are "traveling".
• No loss of efficiency due to packets competing and "waiting" for other packets.
• No need to mess with pipe bridges to overcome packets going the wrong way
• A lot simpler and more intuitive.  No need to identify which end of the pipe is "output" vs "input" or which direction to place bridges.
• Performance boost.  Only need to compute the fluid for the entire network, vs every single block in the network

 

[Gwido]

I think the system is quite good as it is.

 

The only thing i would change, is that a pipe after a pressure valve could not have more water inside than the amount set on the valve.

But it's just a detail to simplify the management of settings which need a low pressure and where we don't want to see 10 kg of water inside a pipe.

[Sasza22]

The problem with handling it like the electric grid is that you need to have a lot of "dead" liquid in the pipes to maintain the pressure. When you run out of liquid the pressure falls and the liquid is stuck in pipes. Long pipes would require a lot of extra liquid to work.

The second thing is heat conductivity. Currently liquids are great to transfer heat. If whe change it like that the system won`t be able to keep track of the temperature of individual packets and would have to average the temperature of the entire pipe system. This would break a ton of designs.

Finally how would you differentiate between different liquids in the system? And how would filters work?

[withers]

3 hours ago, Sasza22 said:

The problem with handling it like the electric grid is that you need to have a lot of "dead" liquid in the pipes to maintain the pressure. When you run out of liquid the pressure falls and the liquid is stuck in pipes. Long pipes would require a lot of extra liquid to work.

Not really.  Play around with Factorio and look at how they handle fluids.  There's no problems like that at all.  Consumer inputs change in proportion to pressure.  A perfectly efficient system is one where total pump input = total consumer output.  Larger/More pumps leads to higher pressure.  More consumers leads to lower pressure.  It's beautiful. 

 

3 hours ago, Sasza22 said:

The second thing is heat conductivity. Currently liquids are great to transfer heat. If whe change it like that the system won`t be able to keep track of the temperature of individual packets and would have to average the temperature of the entire pipe system. This would break a ton of designs.

I see that as an improvement to the design since it allows one to regulate and precisely control temperature, allow more efficient designs.  Check out some of the youtube videos out there where people show how they use reservoirs, which already average the fluid temps, to precisely regulate temperatures.  It allows the player a lot more control.

 

3 hours ago, Sasza22 said:

Finally how would you differentiate between different liquids in the system?

The reservoirs added in the most recent update manage to overcome this "problem" quite easily.  I currently use reservoirs to store mixed fluids and filters to separate where needed. 

 

3 hours ago, Sasza22 said:

And how would filters work?

Exactly like you'd expect.  They would remove the filtered element and add it to a different network.   I imagine filters would have some sort of pressure rating/setting to define how fast elements can be filtered out.

[Gwido]

Factorio is not ONI. The two games don't have to run with the same fuild management.

And ONI works great with his fuild management.

[babba]

I guess we actually like how the current gas and liquid systems works, but from the perspective of frame rate improvements for all players, the good solution from member withers would make the gas & liquid system behave like ONI`s electricity and Factorios gas & liquid system > Having the outlook of great FPS improvements if done right by Klei.

I probably have laid 1000000 pipe pieces in the ONI game, every single connection eats a portion of cpu time, especially as fluid or gas travels in them. Even if its just simple A to B connections. Not even talking of diversions or vents. The problems are instantly visible in debug, as on clones pipe systems which would take a player thousands of cycles to get too ( and then being stuck in the FPS pipe,pathfinding & automation cpu jam ).

Players are cutting down their automation, designs or gameplay style due to ONI`s frame rate issues.

Pathfinding, gas/liquid pipes and automation are the three major issues which can permanently drag a players game speed down. Every player will or has experienced it. People either adjust their build methods, build sizes, automation systems or tear down stuff...Or stop playing the game.

Just by removing the flow direction check of liquids and gases, the games FPS would probably be recovering quite a lot on large and/or automated pipe systems, if changed to a general pressure system. Other steps for Klei would be to further work on pathfinding and automation optimization + user reported rocket crashes and bugs.

[withers]

24 minutes ago, Gwido said:

Factorio is not ONI. The two games don't have to run with the same fuild management.

And ONI works great with his fuild management.

I disagree.  Maybe I just haven't played as much as others -- only really did my first "proper" game after the last update.  But I've spent WAY too much time fighting the inefficient and confusing "packet" system.  It works fine as long as you have one input and one output, but as soon as you start adding multiple pumps / equipment to the system, it gets difficult to manage quickly.  Gases get lost trying to figure out which direction to flow and sometimes the system stops working completely.   I get particularly annoyed when my pump which should be adding 10kg / sec only adds 5/kg because I made the "mistake" of using a fork and one of the branches in the fork is full.  Yes these can mostly be overcome by playing tricks with bridges, but that gets way too complicated and unintuitive too fast, especially for new players like myself

 

[babba]

ONI`s system often reminds me of the failed last SimCity, with their "Agent system" traveling down the pipes. Big funded by EA, the last SimCity installment got the second name "Sim Village". The ONI pipe system would be ok for most players PC`s if the map size would be decreased again - Down to 20%. We dont want that.

I like the current ONI pipe system, Im ok with that in terms of functionality > But it takes too much cpu load.

Any game classified as good by the majority of players, also allows for "Stupid building". If a player does stupid building in ONI, the game is stuck in glue jam. This has nothing to do with dumbing the game down, its about having a system in place which enables the majority of buyers to run it at a decent frame rate.

[Hexicube]

Performance is not a good argument for using Factorio's fluid management, considering that fluids are the least efficient part of Factorio and are one of the current targets for optimising. Reservoir-type stuff also wouldn't really work either, as noted by the "averaging a giant network" issue.

I'm not sure there's a good solution to the problem outside of an alert pointing out directionality issues with pipe networks. The pipe view could show arrows dictating how flow works, and areas that are two-way give a notice to the player...something like "Two-way flow possible, replace with a liquid bridge to pick direction." would explain the problem and give a solution.

The biggest issue that I see with the current pipe system is not the mechanics, but the conveying of information. It doesn't need to be dumbed down, it just needs to actually say what the problem is.

[babba]

Im OK with how ONI does it in terms of gameplay. Its just that laying a short straight pipe with resource flow, from ResourceSupplierA to ConsumerB,  takes too much cpu load. In combo with the dupes pathfinding and the cpu heavy automation its all sums up to the lag festival.

[Gwido]

7 hours ago, babba said:

I guess we actually like how the current gas and liquid systems works, but from the perspective of frame rate improvements for all players, the good solution from member withers would make the gas & liquid system behave like ONI`s electricity and Factorios gas & liquid system > Having the outlook of great FPS improvements if done right by Klei.

If I'm not wrong, you've told that you're always play "factorio style", in debug mode. And for what I see on screen you've posted, you're the type who make giant systems, with lot of added geysers and volcanoes.

 

On my side, my current base run whith 6 duplicants, and after the cycle 1200, it's still working with a good frame rate.

 

Maybe you should consider to play ... "ONI style" ?

Asking to change a pipe system to improve the frame rate when running giant bases that use lots of resources ... well ...   

[babba]

Hey Gwido Im very glad that the game runs well with your excavated tile amount and the amount of things you have used.

Im also trying to speak up for those which are not happy with the games speed. No doubt that the game runs well with a rather small part of the map excavated, with low or standard amount of automation, no jetpackers, no rocket etc.

Some players would like to be able to play the game on a gaming notebook or on their low - mediocre spec PC, feeling frame rate limited to  excavate the entire map or only able to build a decent amount of automation.

Yes, it is correct that I try to get the max out of the game. Originally I was a standard player suffering fom low game speed, due to playing the game with too many cpu cores.

If Klei limits the map size to your screenshot base size, the game is likely to run ok with for lots of players if they dont load it with lots of automation. I like to play at least with the full excavated default map size.

[Alfons100]

But.. this creates three problems, one is- what happens when there’s two liquids in a pipe?

And secondly, will that liquid just turn into one entity in the pipe? In Factorio, there is only ’liquid’, but in ONI there are liquids with different temperatures and bacteria, how will all the liquid mend together as you claim?

Finally, thirdly, sometimes you want liquids to stop and wait, like a radiator loop. 

Maybe I read what you said wrong, but those issues would mess a lot of things up

 

Though, some parts of this idea actually sound kind of good. There should be a ’heavi-liquid pipe’ that is a whole tile, uses its own pipe made out of Refined metals and chews a lot of power. And works as you explain. To allow us to move liquid a whole lot faster without having wide busses of all the same liquid, since one pipe can only ever move 10kg. 

[withers]

3 hours ago, Alfons100 said:

But.. this creates three problems, one is- what happens when there’s two liquids in a pipe?

And secondly, will that liquid just turn into one entity in the pipe?

This happens....

 

It's simple.  Just keep track of whatever is inside the pipe network, like they already do with reservoirs.

To better understand what I'm talking about,  imagine the above reservoir functioning the same way it already does, but with the following differences:

1. The shape of the reservoir is whatever shape the pipe network has made.
2. There's are inputs / outputs to the reservoir everywhere you've added a connecting piece of equipment.
3. The capacity of the reservoir = the number of pipe sections x 10kg.
4. Outside connections are able to draw from the reservoir based on the pressure inside x 10kg.  (or using some simplified version of fluid mechanics formulas)
5. It exchanges heat with surroundings at each tile, using normal heat exchange mechanics and based on the pressure inside (total amount / capacity) x 10 kg for each fluid. 

Quote

Finally, thirdly, sometimes you want liquids to stop and wait, like a radiator loop.

If the temperature of all the fluids in the network are averaged, you don't need a loop.  Just continue adding hotter/colder fluid to the pipe network until the average reaches the temperature you want.    Or if you do have an actual loop, such as with a thermal regulator, we just treat the thermal regulator as a separate container with both an input and an output.  (like it already is).

[Hexicube]

1 hour ago, withers said:

If the temperature of all the fluids in the network are averaged, you don't need a loop.  Just continue adding hotter/colder fluid to the pipe network until the average reaches the temperature you want.    Or if you do have an actual loop, such as with a thermal regulator, we just treat the thermal regulator as a separate container with both an input and an output.  (like it already is).

This is a flawed argument, you don't always want everything to be the same temperature. I can easily see some sort of cooling loop using an AETN that first cools some sleet wheat to 0C, and then goes to cool a bristle farm to 15C. If the entire network is averaged, either the sleet wheat is too hot or the bristle blossoms are too cold, as they both have a 5C cut-off.

It doesn't even need to be two separate lengths of pipe with a valve, it can be a single long pipe too. Heat reclaiming designs on volcanoes typically route the entering fluid in the opposite direction across the exhaust so that the resultant gas is cooled and the fluid is pre-heated. This stops working with your proposal, as it instead attempts to heat the entire pipe as a single thing, making the design less efficient as it is pre-heated less and the exhaust is hotter. Sour gas processing is likely to use this trick for extreme efficiency designs, to maximise the throughput of a single aquatuner, and is something I'm working on designing.

[withers]

Hi Hexicube. If you are arguing that my proposal would break current designs in any particular saved game, I have no defense.  Yes.  Making changes to a game does tend to do that.  It's the nature of participating in early access. When that happens, you make adjustments to meet your objectives and move on.

Both of your examples could be easily addressed by adding a valve to split the network into two networks.  (Remember, a network would be defined by every connecting piece of pipe, which a valve splits up into two).  I never said you have to treat all pipe in the base as one giant network.  That would be silly.  If you wanted to use a single "loop" to cool multiple different parts of your base to two different temperatures, just split it into two networks. (or multiple networks, as you see fit)  My arrangement would actually make this easier, since you could set sensors / regulators to adjust each segment (network) in your loop making precise adjustments to the average temperature for each network.  Actually, I can imagine anyone try to accomplish your first example under the current system would be facing a nightmare as they'd be constantly having to guess the average temperature for each part of their system in order to figure out if they need it to be cooler or hotter. My proposal allows for precise adjustments and automated fine tuning of each part of the system.

Easy peasy lemon squeezy. 

[Hexicube]

That's not what I'm arguing. What I'm arguing is that what you're suggesting just makes it more opaque, when the currently system only requires flow indicators on the pipe overlay to solve confusion, and that what you're proposing doesn't solve your own listed problems.

Here's what you want to achieve:

On 10/11/2018 at 2:42 AM, withers said:

• No confusion over which direction fluids are "traveling".
• No loss of efficiency due to packets competing and "waiting" for other packets.
• No need to mess with pipe bridges to overcome packets going the wrong way
• A lot simpler and more intuitive.  No need to identify which end of the pipe is "output" vs "input" or which direction to place bridges.
• Performance boost.  Only need to compute the fluid for the entire network, vs every single block in the network

Three of these (1,2,4) are solved by having a flow indicator (2 is solved indirectly). Your proposal replaces 3 with a different nuance of having to add valves in order to separate piping so that it can have different properties, and your proposal replaces the performance cost of individual packets with the performance cost of a thermal system capable of exchanging heat with many tiles at once.

I have yet to see an argument on how the current system is bad that isn't also solved by simply adding more information to the interface, or a solution that actually does solve the performance "problem" without merely moving it elsewhere.

[blash365]

I like the current fluid system. It is very powerful and fits exactly into the ONI world.

Maybe pressure could be incorporated in it, but i would not want to lose the single-package-tracking down the pipes.

Possible things to improve:

• Pressure (if possible to combine with current system)
• bigger pipes (maybe even with multiple elements in it)
• more elaborate pipe elements (Y-element, X-element), which split packages in evenly in all connected directions.