Factorio Forums

.

Yoyobuae wrote: Sun Feb 07, 2021 6:53 pm I prefer to work on actual data rather than rumors or hearsay.

I probably shouldn't humor you, because the issues are well-documented elsewhere, and your ignorance is showing.

Pipes are very expensive CPU-wise. Megafactory builds often try to avoid nuclear power because of the CPU burden of the fluid simulation that it adds. This is because a fairly complicated calculation needs to be performed on each pipe, whereas many other things can be optimized with timers and such in the implementation, avoiding much of the update cost.

The problem isn't that there's no way to optimize a fluid network, but that the game's mechanics seriously constrain what you do unless you want to over-build your junctions. Let's say that I want to distribute 1k fluid per second into a pile of assemblers making rocket fuel. In practice, this will require most of the throughput of a single pipeline. The tricky part is that I basically have to avoid intersections like the plague, or else I will end up with arbitrary bottlenecks due to game weirdness. That means the assemblers have to be arranged in a manifold configuration, unless I want to have an over-built pipe intersection to work around the bottlenecking issues, which is expensive in terms of pipes, space, and CPU.

When you are forced to build pipe junctions due to other design constraints, things get really awful. Because the behavior is inconsistent, I cannot predict how a particular junction is going to behave. Period. This makes efficient engineering basically impossible. Instead, I have to put worst-case bounds on the junction's predicted behavior based on the worst possible behavior that the system could throw at me, and this typically results in me building junctions between m and n pipes as m*n grids of pipe pieces, because that's the only thing that I can guarantee will work. If we had the alternate system that had been proposed and prototyped, we would be able to solve for steady-state behavior of pipe networks with ease - in fact, you could use tools like circuit solvers to do it for you.

For another example of how this fluid system makes life difficult, you cannot build factories that inherently maintain symmetric consumption/production when fluids are involved, because when fluid levels drop below what is required to maintain maximum throughput, junctions will behave asymmetrically. There are reasons that you might want to do this when interacting with certain train station designs, and it is easy to do with belt-only designs. Factories that handle fluids, on the other hand, now require belt balancers in order to work around the game's nonsensical fluid behaviors, which take up space and can get quite complicated when dealing with larger numbers of belts.

Zistack wrote: Sun Feb 07, 2021 8:33 pm Pipes are very expensive CPU-wise. Megafactory builds often try to avoid nuclear power because of the CPU burden of the fluid simulation that it adds. This is because a fairly complicated calculation needs to be performed on each pipe, whereas many other things can be optimized with timers and such in the implementation, avoiding much of the update cost.

As was stated earlier in the thread, pipe OPTIMIZATIONS are already in - pipes are much much faster than they used to be, especially since nuclear systems first came out. Problem with nuclear isn't pipe calculations. Those are relatively small compared to the heat calculations. My nuclear powered 1K SPM megabase spends ten times longer on the heat manager than it does the fluid manager - 0.500 for heat, and 0.060 for pipes. Importantly, keep in mind the heat manager is only used for those reactors, while the fluid manager is also managing all the other pipes in the base.

The only thing the rework had left to work on was making flow more predictable, which would have made the simulation slower, not faster. Pipes are already as fast as they were ever going to be.

.

Yoyobuae wrote: Mon Feb 08, 2021 4:28 am This setup has the highest potential for causing the issues you claim to happen, yet they all work just fine.

Have you tried to reduce fluid feed? Just to watch what will happen.

coppercoil wrote: Mon Feb 08, 2021 8:29 am

Yoyobuae wrote: Mon Feb 08, 2021 4:28 am This setup has the highest potential for causing the issues you claim to happen, yet they all work just fine.

Have you tried to reduce fluid feed? Just to watch what will happen.

I suspect that feeding the factory with less than what it needs to produce at full speed might make it produce less than at full speed. I would be very surprised if that weren't the case.

.

Yoyobuae wrote: Mon Feb 08, 2021 4:28 am No, it's not due to pipes.

80% of the UPS impact of a nuclear powerplant is due to steam engines and heatexchangers.

yeah, it's due to fluids.

...which steam engines and heat exchangers have inside.

otherwise why do you suppose they're more expensive than solar panels? please enlighten us.

.

ptx0 wrote: Mon Feb 08, 2021 2:33 pm otherwise why do you suppose they're more expensive than solar panels?

You just can't compare them to solar panels. Nuclear power will never ever, ever (!) be competitive with solar panels if you want to optimise ups. For solar panels it doesn't matter how many you have it takes the same ups (a tiny amount) as all of them get updated as if they were one entity. For good reasons heat exchangers and turbines need to be updated individually.

As for the original topic of this post: Pipes are already way better than they used to be. I never encountered an issue that wasn't created by bad design and that I couldn't solve. As a general rule: just don't use input starved designs and accept that like in real life fluids loose pressure over long distances and small amounts don't split equally on forks. Sorry for the harsh words but I honestly feel like most people complaining about the fluid system don't really know what they are talking about but are just repeating what others have said years ago. Please prove me wrong.

Also the devs made pretty clear that they don't want to work on this any time soon, since the people who understood how the current system works internally are no longer working at Wube.

Yoyobuae wrote: Mon Feb 08, 2021 2:28 pm Some of them stop working. Which ones? Who cares!

You should not look at this issue from a megabase-builder position. Smaller factories share the same pipeline for different productions (say, A+B), so if we cut the feed to 0.5, then we can get 1*A + 0*B instead of 0.5*A + 0.5*B. So, many players care about it.

coppercoil wrote: Mon Feb 08, 2021 2:54 pm

Yoyobuae wrote: Mon Feb 08, 2021 2:28 pm Some of them stop working. Which ones? Who cares!

You should not look at this issue from a megabase-builder position. Smaller factories share the same pipeline for different productions (say, A+B), so if we cut the feed to 0.5, then we can get 1*A + 0*B instead of 0.5*A + 0.5*B. So, many players care about it.

Allow me to quote one of the devs :

Rseding91 wrote: Sun Jan 31, 2021 4:33 pm Splitting is not required. If you ever think you need to split fluid it means you don't have enough fluid.

Koub wrote: Mon Feb 08, 2021 3:09 pm Allow me to quote one of the devs :

Allow me to quote myself :

coppercoil wrote:

Rseding91 wrote: Sun Jan 31, 2021 4:33 pm Splitting is not required. If you ever think you need to split fluid it means you don't have enough fluid.

Not enough fluid - not so rare situation.

.

Yoyobuae wrote: Mon Feb 08, 2021 4:22 pm If you want to split fluids, then use a fluid splitter:

Does not work. Copy blueprint

coppercoil wrote: Mon Feb 08, 2021 4:43 pm

Yoyobuae wrote: Mon Feb 08, 2021 4:22 pm If you want to split fluids, then use a fluid splitter:

Does not work.

You might add a wire, if fluid greater 1000, then activate both pumps

jodokus31 wrote: Mon Feb 08, 2021 4:46 pm You might add a wire, if fluid greater 1000, then activate both pumps

That's called "workaround". If you play like a pro, you can really fix many things. Average and newbie players cannot do that.

As stated earlier: these issues only occur if you are lacking enough input.

Let's say you want to produce product 1 (P1) and product 2 (P2) from a liquid ingredient. You need both products to advance, otherwise you would focus on one thing and stop the production of the other one. It doesn't make any difference if you produce P1 first and then P2, or P2 first and then P1 or both of them at the same time. It will take the same time either way. Equally balancing the ingredients between the to products is therefore unnecessary.

Instead of blaming the fluid system one should therefore either build more production or prioritise on the product you need the most of.

ickputzdirwech wrote: Mon Feb 08, 2021 5:10 pm It doesn't make any difference if you produce P1 first and then P2, or P2 first and then P1 or both of them at the same time.

No. It makes the difference to the question "do fluids work as expected?". This is how players think.
You can say "you will still launch the rocket in XX hours". This may be true, but this is not how non-pro players think. Players want smooth gameplay. A technology that is not intuitive, gives bad impression "now and here", regardless of "general long-time performance".

Silari wrote: Sun Feb 07, 2021 9:42 pm

Zistack wrote: Sun Feb 07, 2021 8:33 pm Pipes are very expensive CPU-wise. Megafactory builds often try to avoid nuclear power because of the CPU burden of the fluid simulation that it adds. This is because a fairly complicated calculation needs to be performed on each pipe, whereas many other things can be optimized with timers and such in the implementation, avoiding much of the update cost.

As was stated earlier in the thread, pipe OPTIMIZATIONS are already in - pipes are much much faster than they used to be, especially since nuclear systems first came out. Problem with nuclear isn't pipe calculations. Those are relatively small compared to the heat calculations. My nuclear powered 1K SPM megabase spends ten times longer on the heat manager than it does the fluid manager - 0.500 for heat, and 0.060 for pipes. Importantly, keep in mind the heat manager is only used for those reactors, while the fluid manager is also managing all the other pipes in the base.

The only thing the rework had left to work on was making flow more predictable, which would have made the simulation slower, not faster. Pipes are already as fast as they were ever going to be.

Alright, so the pipe CPU optimizations were more effective than I thought they were. Good to know. My other points still stand.

As far as the predictable flow goes, if I don't need as many pipes, then I save on CPU time (even if that is already negligible). As long as the proportion of pipes that I save due to predictable flow is greater than the proportion of slowdown I get from the new system, I still win on performance.