Re: Is the Fluid Rework still planned?
Posted: Sun Feb 07, 2021 6:53 pm
.
I probably shouldn't humor you, because the issues are well-documented elsewhere, and your ignorance is showing.
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.Zistack wrote: ↑Sun Feb 07, 2021 8:33 pmPipes 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.
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.coppercoil wrote: ↑Mon Feb 08, 2021 8:29 amHave you tried to reduce fluid feed? Just to watch what will happen.
yeah, it's due to fluids.
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.
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 :coppercoil wrote: ↑Mon Feb 08, 2021 2:54 pmYou 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.
You might add a wire, if fluid greater 1000, then activate both pumps
No. It makes the difference to the question "do fluids work as expected?". This is how players think.ickputzdirwech wrote: ↑Mon Feb 08, 2021 5:10 pmIt 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.
Alright, so the pipe CPU optimizations were more effective than I thought they were. Good to know. My other points still stand.Silari wrote: ↑Sun Feb 07, 2021 9:42 pmAs 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.Zistack wrote: ↑Sun Feb 07, 2021 8:33 pmPipes 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 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.