Factorio Forums

Remove flow mechanics entirely. Just like durability and pickaxes were removed entirely and no one looked back.

Hear me out: when someone is designing a factory, having to wrestle fluid resistance and pumps that don't add pressure is not fun. All people want is to get stuff from point A to point B. So why not treat pipes like electric poles? If X is being served from somewhere and somewhere else can consume X, just make it get there. We are halfway there with fluid mix prevention anyway.

Bonus points: no more performance and parallelization issues.

Hmm, it has the charm of a problem being solved with a sledgehammer (solving problems with a sledgehammer does have some charm).

Pros:
-It would work
-Perfomance and easy to code
-I probably wouldn't be able to tell the difference

Cons:
-I've never built anything large, there may be large-scale effects where fluid mechanics are relevant
-It's pretty drastic, there may be unexpected consequences
-I don't know but it kinda feels sad.. though yeah, I probably wouldn't look back.. much

Worth trying, I guess

I like fluids beeing different from belts and power grid (the latter is rather boring). I also did not build any megabase yet (and also don't plan to do that). But i did notice the occasional need to add pumps here and there. I like that. It makes it less magical and more like real fluid networks.

It would be nice to have a choice: vanilla slow fluid pipes or modded high speed and UPS friendly pipes. It can be added as another prototype type, just hidden in vanilla, same as loaders.

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:41 am

All people want is to get stuff from point A to point B.

Well, no. Sometimes I want to get stuff from points A1 and A2 to points B1, B2, B3, B4, B5, B6, B7, B8, B9, B10 and B11.

Pretty sure "infinite flow speed" was one of the candidates when the fluid optimization disucussion started. Which means it was discarded as too sledgehammery during the original discussion and is unlikely to come back.

Deadlock989 wrote: ↑

Thu Jul 11, 2019 8:25 am

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:41 am

All people want is to get stuff from point A to point B.

Well, no. Sometimes I want to get stuff from points A1 and A2 to points B1, B2, B3, B4, B5, B6, B7, B8, B9, B10 and B11.

What the logic must be by
production_summ(A) < consumption_summ(B)
and
production_summ(A) > consumption_summ(B)?

darkfrei wrote: ↑

Thu Jul 11, 2019 10:16 am

Deadlock989 wrote: ↑

Thu Jul 11, 2019 8:25 am

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:41 am

All people want is to get stuff from point A to point B.

Well, no. Sometimes I want to get stuff from points A1 and A2 to points B1, B2, B3, B4, B5, B6, B7, B8, B9, B10 and B11.

What the logic must be by
production_summ(A) < consumption_summ(B)
and
production_summ(A) > consumption_summ(B)?

The infinite flow model is simple: All the pipe (and tanks) in the fluid system act as one big buffer. Every tick each producer adds their output to the buffer and each consumer removes their input from it. When the buffer gets full or empty less than the full potential is added or removed and you have to decide how to split that up.

1) Every entity simply gets 1/N of the amount
2) Every entity gets <speed of his entity> / sum <speed of entity>
3) Every entity gets <amount in this fluid box / amount free in this fluid box> / sum <amount in fluid box / amount free in fluid box>

or the like.


It would indeed be a very simply fluid system. But infinite flow would break any setup that depends on a limited flow. Producers and consumers would no longer have priorities, even if those are currently somewhat chaotic. Remember that vanilla has no flow control valves, only pumps. Currently you can give some entities priority simply by where you place them along a pipe and this being used.

eradicator wrote: ↑

Thu Jul 11, 2019 9:32 am

Pretty sure "infinite flow speed" was one of the candidates when the fluid optimization disucussion started. Which means it was discarded as too sledgehammery during the original discussion and is unlikely to come back.

I never said anything about infinite flow. There could still be speed taken in account. For example, if you have a single pump pushing into a system but you have comsumption that exceeds the pump flow speed, then the consumers would have to wait. What I am talking about is just removing the flow calculation and skipping straight to getting fluids to the consuming ends of the system.

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:03 pm

I never said anything about infinite flow.

Neither did i. I said infinite flow speed.

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:03 pm

eradicator wrote: ↑

Thu Jul 11, 2019 9:32 am

Pretty sure "infinite flow speed" was one of the candidates when the fluid optimization disucussion started. Which means it was discarded as too sledgehammery during the original discussion and is unlikely to come back.

I never said anything about infinite flow. There could still be speed taken in account. For example, if you have a single pump pushing into a system but you have comsumption that exceeds the pump flow speed, then the consumers would have to wait. What I am talking about is just removing the flow calculation and skipping straight to getting fluids to the consuming ends of the system.

"infinite flow speed" ("how fast does it get there?") is what you described in your opening post. "infinite throughput" ("how much of it gets there?") is what you described just now. If you want to continue this discussion you need to use consistent and precise vocabulary for the things you describe.

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:41 am

when someone is designing a factory, having to wrestle fluid resistance and pumps that don't add pressure is not fun.

That's basically why I play Factorio, to solve puzzles like that. If everything just teleported from outputs to inputs this wouldn't be much of a game.

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:41 am

All people want is to get stuff from point A to point B. So why not treat pipes like electric poles? If X is being served from somewhere and somewhere else can consume X, just make it get there. We are halfway there with fluid mix prevention anyway.

If you look through this forum for suggestions about the electric network, you'll find a lot of people (myself included) who think the electrical network is too simple and that it should work a bit more like fluids. And it's a lot easier for a mod to make a complicated system simpler than it is for a mod to make a simple system more complex... So I think the "fast fluids" could be done with a mod for people who want that feature.

The end goal is getting items from point A to point B, but that's also the main challenge that makes the game interesting. I kinda feel like if you're gonna start removing those constraints you might as well just design your base in Photoshop

It looks like gas physics, by the A we make the pressure higher, by the B we make it lower.

I think urza99814 summed up my feelings on this fairly well.

Personally, I feel as though half the issues with the current system and probably what causes most of the dislike for it is that currently it doesn’t work all that well/has bugs in it. If those were fixed and everything flowed better/the way it’s expected, then it’d be awesome.

mrvn wrote: ↑

Thu Jul 11, 2019 10:38 am

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:41 am

Well, no. Sometimes I want to get stuff from points A1 and A2 to points B1, B2, B3, B4, B5, B6, B7, B8, B9, B10 and B11.

one big buffer.

The current model supports some respect of distance of producers>consumers, generally giving priority to closer consumers. E.g., when there is scarcity the closer consumers will get some fluid while farther ones will starve. In addition the current model allows for pumps to ensure you can prioritise consumers. (e.g., my plastics plants get served first, then optionally my sulfur production for batteries, then third sulfur for explosives)...

I know there are optimisation plans for the future so I will reserve a bug report until then:
https://wiki.factorio.com/Roadmap

urza99814 wrote: ↑

Thu Jul 11, 2019 1:04 pm

That's basically why I play Factorio, to solve puzzles like that. If everything just teleported from outputs to inputs this wouldn't be much of a game.

The issue is that flow mechanics don't add complexity, it just adds a hard limitation. You literally can't solve a problem when there is a limit on how much fluid can reach a certain point.

StephenLynx wrote: ↑

Thu Jul 11, 2019 8:10 pm

urza99814 wrote: ↑

Thu Jul 11, 2019 1:04 pm

That's basically why I play Factorio, to solve puzzles like that. If everything just teleported from outputs to inputs this wouldn't be much of a game.

The issue is that flow mechanics don't add complexity, it just adds a hard limitation. You literally can't solve a problem when there is a limit on how much fluid can reach a certain point.

How is that different from belts? Belts can only transport just so much per second. If you need more, add another pipe (belt).

With pipes, you also should make sure that you're using a pump every few pipe segments to keep the pressure up. There's a chart on the wiki and you can use that to determine whether doing pumps more frequently or more separate pipe lines meets your needs better.

FuryoftheStars wrote: ↑

Thu Jul 11, 2019 8:21 pm

How is that different from belts? Belts can only transport just so much per second. If you need more, add another pipe (belt).

Belt's output won't change based on distance. You can tile layouts as far as you want. You can't do that with pipes because they will just stop outputting stuff at a certain distance.

StephenLynx wrote: ↑

Thu Jul 11, 2019 12:03 pm

eradicator wrote: ↑

Thu Jul 11, 2019 9:32 am

Pretty sure "infinite flow speed" was one of the candidates when the fluid optimization disucussion started. Which means it was discarded as too sledgehammery during the original discussion and is unlikely to come back.

I never said anything about infinite flow. There could still be speed taken in account. For example, if you have a single pump pushing into a system but you have comsumption that exceeds the pump flow speed, then the consumers would have to wait. What I am talking about is just removing the flow calculation and skipping straight to getting fluids to the consuming ends of the system.

This. Calculate along the pipeline the "minimum throughput" component, then limit the device past it to that. No flow mechanics: you have a "100 throughput" pipe, you get "100 throughput" everywhere beyond it, and no more. This makes (a) different pipe tiers more interesting like tiered power poles, (b) requires a one-time calculation on each pipeline if, and only if, a connection changes, and is "intuitive" if actually wrong about how a pump and pipe will work.

Flow is still limited, but it isn't limited based on an internal simulation, it is limited based on a pretty stupid black box model of a fluid system. Easy, intuitive, and completely wrong for how real fluids behave ... but I think a good choice for the game, at least compared to how unintuitive the current system is.

StephenLynx wrote: ↑

Thu Jul 11, 2019 9:12 pm

FuryoftheStars wrote: ↑

Thu Jul 11, 2019 8:21 pm

How is that different from belts? Belts can only transport just so much per second. If you need more, add another pipe (belt).

Belt's output won't change based on distance. You can tile layouts as far as you want. You can't do that with pipes because they will just stop outputting stuff at a certain distance.

Pretty sure my second paragraph you deleted from the quote concerning pumps covers that.

FuryoftheStars wrote: ↑

Thu Jul 11, 2019 11:53 pm

Pretty sure my second paragraph you deleted from the quote concerning pumps covers that.

You simply can't fit pumps everywhere. Because not only you require the space for the pump itself, but also to provide electricity to it. It still doesn't compare to a belt. And mind you, unless you have a long, unbending series of pumps, you will lose output based on the distance. Using pumps to make up for a system deficiency doesn't excuse the deficiency. And is still an arbitrary requirement.