Simple and interesting 2.0 fluids

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

Post Reply
AkaraVortex
Burner Inserter
Burner Inserter
Posts: 5
Joined: Tue Mar 12, 2024 5:48 am
Contact:

Simple and interesting 2.0 fluids

Post by AkaraVortex »

TL;DR
The new fluid system which will preserve the ease-of-understand of new 2.0 system, fast calculation time, but also will keep some complexity to the fluid managing mechanic.
What ?
=== About old system.
- The throughput is very unclear and not really logical to grasp, it is not written that pipes have a throughput and what is it or how to improve it. Plus flow rate graph is non-sence.
- The liquid behaves strangely on pipe splits. Last steam turbine in array uses steam instead of first one.
- Tank to tank flow is non-sense.
- Cannot handle amounts for 2.0.

+ Some sort of challenge... not the best one, far from the best, but it added some depth to the game.
+ Pseudo realistic behaviour.

However not everything in factorio is clear, i.e., Inserters, and more like how much items per second one inserter will throw into machine from the belt. Logically thinking for bulk inserter: this should be 12 * 864 / 360 items per second, but it is not, and even not for chest to chest. So how do you deal with that? Add more inserters. So with pipes you add more pipes.

=== About new system.
- From realistic perspective behaviour is questionable. Even for wires it is more logical, presume they are just super conductors. But fluids are physical things and they cannot be blastic through pipes at several speeds of sound. Not that game *should* be realistic, gameplay is first, but Factorio keeps itself closer to realistic-industrial aesthetics.

+ Esily to grasp. Yeah sure, because it now has 0 comlpexity.
+ You no longer need to clog your brain with flowrate between pumps.
+ It looks very tidy and perfectionists will be happy.
+ The system can handle amount of liquids for 2.0.


=== Akara's idea for new system:
First, let's acknowledge that belts are simple to grasp, they are clear and exact, and have some depth to them. You need to manage how belts are laid down and how much they can transfer. However you do not need to bother yourself with max length of a belt lines or powering them with electricity or some belt pusher engines.

So why do not make pipes same way?

My idea is simple: Keep everything from 2.0 fluid system but add 1 thing: absolute throughput limit.

Lets say for water this is 6000 units per second per fluid segment. This means each tick all machines can add to the segment maximum of 100 units and also take maximum of 100 units.
Throughput is absolute and fixed regardless of configuration where machines are placed. For belts throughput can be "expanded" if you load and unload belts on the go, but pipes have an advantage in being omnidirectional.

Each pipe has a tool-tip: max flow-rate per segment is 6000 units / second. Or, additionally, for liquid metals it can be set to 600 units.

But issue arises: what if you accidentally connect 2 systems? The flow-rate will be cut in 2, and this is non-intuitive, illogical and just bad.

This is where we have to make pipe segments:
- Pipes with 0-2 connections to other pipes form one segment (like in 2.0), separated by junctions.
- Each pipe with 3 connections or 4 connections to other pipes is its own segment, i.e. junctions.
Machines affect segmentation but do not counts as segments (more about segment optimization on that later), and also prioritize taking / dumping fluid from straight segments and only then junctions.

The flow is back, but it should be instant, each segment / junction pushes its content at max throughput to connected segments to equalize the content between them. To keep flow-rate at max 6000 rate, filled up segments with machines not being able to push liquid in will recursively propagate signal that they are full and cannot take more liquid in, if segment has such nearby segment (with fluid overflow state), it will dump maximum possible amount of content to segments without such state (even if that implies that this segment will become empty).

Also when holding a pipe they highlight different fluid segments, so you can see where can be possible bottlenecks.
Why ?
New fluid system completely destroys all the complexity when working with pipes.
I get that it is done to give road for other mechanics. But remember - we have only 2 crafting ingredient categories: items and fluids. So omitting fluids like electricity is not a fair comparison. It would be the same as giving belts an infinite throughput.

With my idea for new players in the early to mid game fluid system will be not an issue at all, but when going on a megabase scale, it will be not harder to understand than trains. It will be clean and simple as belts, but also give some extent of logistic challenge.
Examples
Machines try to add fluid to the segment, but cannot push out all liquid - segment becomes overflowed.
Overflow from machines.png
Overflow from machines.png (225.02 KiB) Viewed 549 times


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

In the beginning of calculation segment is flagged as overflowed, but hasn't 100% fluid in it, flag removes but calculation still goes as for segment with overflow.
Overflow Lifted.png
Overflow Lifted.png (169.97 KiB) Viewed 549 times


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

Calculating segment which has neighbors with overflow flag:
Segment with neighbor overflow.png
Segment with neighbor overflow.png (370.86 KiB) Viewed 549 times


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

Calculating segment with overflow flag:
Segment with overflow.png
Segment with overflow.png (323.31 KiB) Viewed 549 times


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

If segment and all its neighbors are with same flag / no flag, they just equalize content.

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

Machines add liquid to segment in the beginning of calculation.

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

Machines consume liquid in the end of calculation, even if segment got marked as overflowed in this tick, machine takes from this segment and makes it no longer overflowed.
Overflow Lifted from machine in the same tick.png
Overflow Lifted from machine in the same tick.png (212.7 KiB) Viewed 539 times
Segment optimization
1st. If segment has only 1 connected machine to it, it can be combined will all neighbor segment which have no machines connected to them.
2nd. If segments has only consumer machines and its neighbor has only production machines, segments get combined.
3rd. 2 segments each connected only to output of its only machines gets combined. Same for inputs.
4th. If segment without counting machines as connections has only 1 point of connection to another segment, they get combined.
Attachments
Segment optimization.png
Segment optimization.png (526.29 KiB) Viewed 480 times
Last edited by AkaraVortex on Sun Jun 23, 2024 12:49 pm, edited 3 times in total.

Schrekken
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sun Jun 23, 2024 8:58 am
Contact:

Re: Simple and interesting 2.0 fluids

Post by Schrekken »

I very much agree with this version as it does not render junctions irrelevant and adds some complexity.
Junction and flow direction should very much keep some importance and in this way it seems easy to marry the new fluid system with some level of realism by splitting connected pipes into segments at junctions.

Here's some ideas about flow:
A pipe will have its flow halved when split in two.

Code: Select all

  flow 1           flow 0.5
> > > > > > / x / > > > > > >                   > pipe with direction of flow
              /                                 x junction
              v                                 / separation of segments
              v     flow 0.5
              v
I'm not entirely sure whether you technically need junctions as entities within the logic or if you can or if you can just have the junction be part of a segment, if that simplifies the situation within the code.

Code: Select all

  flow 1           flow 0.5
> > > > > > x / > > > > > >                > pipe with direction of flow
            /                              x junction
            v                              / separation of segments
            v     flow 0.5
            v
If there was no pump involved or any machines adding or reducing the liquid, the pipes would equalize and have the same amount of liquid in them. Without a direction of flow.

Code: Select all

content 0.8           content 0.8
- - - - - - - x / - - - - - - -                       - pipes
              /                                       x junction
              I                                       / separation of segments
              I     content 0.8 
              I
Once an entity is taking or adding liquid to the system the amount of liquid and flowstate would change to something akin to the previous depicitons.

Of course if a pipe segment is being filled and not drained it would not reduce flow to other segments at a junction. The segment would fill up and act as an appendix.

Code: Select all

  flow 1           flow 1
> > > > > > x / > > > > > >                    > pipe with direction of flow
            /                                  - pipe without flow
            I                                  x junction
            I                                  / separation of segments
            I     flow 0 
            I     (nothing moving in or out)
That way an appendix of pipes would act as some sort of low volume storage tank.

I'm not sure whether any state of flow direction needs to be handled by code, since this splitting of fluid throughput between segments would inherently carry a sense of flow direction, from high flow segments to lower flow segments with pumps acting as a oneway flow pipe if connected to pipes only.

Code: Select all

Flow 0.5              Flow 0.5                       - pipes without flow
> > > > > > / [>P>] / > > > > >                      < pipes with flow direction
                                                 [<P<] pump with flow direction
Flow 0.5              Flow 0                         / separation of segments
> > > > > > / [<P<] / - - - - - -   
I like this concept of how fluids should behave in pipes and would like to see something akin to this in factorio as it retains some depth to handling fluids while not making it too easy or be too confusing. This system would also mean, that several pipes for the same liquid would need to be laid in parallel, if there is limited throughput for any pipe segment, which in my opinion would lead to interesting build wherever fluids are necessary. Also it provides the option of having several types of pipes for upgrading, like we have with yellow, red or blue belts, in the form of different pipes providing different volumes or able to handle a higher flow.

Code: Select all

     Flow 1                                                0.5
> > > > > > > > > > > > > > > > > > > > > x > > > > > > > > > > > > > > > > > > > >                                     M = Machine using liquid
                                          v 0.5                                   v 0.5
     Flow 1        0.5       0.25         v                        0.375          v
> > > > > > > > x > > > > x > > > > [>P>] x > > > > > x > > > > > > > > > > [>P>] x > > > > > > > > > > 
                v 0.5     v 0.25              0.75    v 0.375                               0.875
                M         M                           M
At this point it is important to keep in mind that the displayed values are flow rate, not the amount of liquids stored in the pipes, as the machines have a lower rate of consumption than the flowrate of pipes. Therefore in practice the flow rate numbers given in the depiction would be higher, as the liquid put in the machines would back up, fill the pipe segment and not lower the flow throughput to the second exit nearly as much as 50%. Instead the pipe segments leading into a machine would act like an appendix, but slowly be drained, as the liquid is beeing used.

I hope you like the idea and I'd love to get some feedback on this!
Last edited by Schrekken on Sun Jun 23, 2024 12:09 pm, edited 2 times in total.

RobotMan2412
Manual Inserter
Manual Inserter
Posts: 3
Joined: Mon Aug 28, 2023 11:36 pm
Contact:

Re: Simple and interesting 2.0 fluids

Post by RobotMan2412 »

+1 for this one, it buffs fluids while still not completely trivializing them.

AkaraVortex
Burner Inserter
Burner Inserter
Posts: 5
Joined: Tue Mar 12, 2024 5:48 am
Contact:

Re: Simple and interesting 2.0 fluids

Post by AkaraVortex »

Schrekken wrote:
Sun Jun 23, 2024 12:01 pm
I hope you like the idea and I'd love to get some feedback on this!
Yes, you are pretty much on point with what I was thinking.

With your post you've covered how exactly fluids will act on junctions. However in my system such notion as a flow is somewhat reduced, as I want to focus on keeping it simple, as in 2.0, where in some way flow is gone.

But what you are describing does perfectly expand my words "liquids will be equalized" and how exactly these units will be transferred between segments.

Post Reply

Return to “Ideas and Suggestions”