Friday Facts #416 - Fluids 2.0

[Succ-Orange]

This adds far more realism than it removes. I don't like how the flow thing existed and became more important than other real things.
1) Pumps wouldn't evenly flow out of junctions, now they do, just like real life
2) Before pumps at the back of a system wouldn't push the rest of the fluids along, now it does, just like real life.
3) pumps are now no-longer needed every 20 meters... just like real life
4) pipes used to flow back and forth before equilibrium, this is NOT like real life, there's too much friction for this in real life. Once it's evenly distributed it sits there.

Nobody asked for that wave feature in pipe fluids, and we'd all wait until that pipe stopped flowing before we decided if we were happy. It was neither useful, realistic nor good for performance. It was in the game because someone made it and there was a lost cost fallacy going on.

[Blacky007]

Hello @raiguard

for Uranium ore I use a tank-pipesystem - the Tank is filled until 1000 and starts filling again at 500 - this way I only have a low amount of sulfuric acid in the gigantic miner array.
does the new system effect this system or are there no problems?

Greetings Blacky007

[GregoriusT]

Important Question: Will Underground Pipes have dynamic capacity depending on the distance they cover?

I really want to run a non-underground pipe for once without feeling like doing everything wrong.

[Svip]

How about making fluids quantities an integer number rather than a real number? A machine would typically consume 1 unit of fluid, and fluids would not split in quantities lower than 1.

I am not sure what the purpose of this suggestion is, but fluids are already in integers. A storage tank can hold 25000 units of fluid precisely to avoid using floating numbers.

Uhhh there is frequently a decimal separator in my Pipes so I am not sure if you understand what that means, even if it was fixed point integer with 250000 units, it still has issues.

I stand corrected; what an odd choice. Considering the values of fluid, I thought it was to avoid floats entirely. I do not see any need for the fluids to be floating point numbers.

Edit: Unless, of course, that they are really integers below, and then divided by 10 or 100 for show, but I doubt it.

[o6dukeleto]

This adds far more realism than it removes. I don't like how the flow thing existed and became more important than other real things.
1) Pumps wouldn't evenly flow out of junctions, now they do, just like real life
2) Before pumps at the back of a system wouldn't push the rest of the fluids along, now it does, just like real life.
3) pumps are now no-longer needed every 20 meters... just like real life
4) pipes used to flow back and forth before equilibrium, this is NOT like real life, there's too much friction for this in real life. Once it's evenly distributed it sits there.

Nobody asked for that wave feature in pipe fluids, and we'd all wait until that pipe stopped flowing before we decided if we were happy. It was neither useful, realistic nor good for performance. It was in the game because someone made it and there was a lost cost fallacy going on.

Maybe the FFF should have said Realism instead of Fun?

I suspect you could add another

5) IRL pipes are more optimal than trains for transporting fluids

Personally, I think Realism is a poor reason for game mechanics, fun is more important. Realism will always be abstracted in some way for a game, hence using it as a reason is very subjective.

I do think having an optimal solution of using a single pipe per resource (fluid/gas) is less fun. I also do not like the current implementation, but I do think the proposed solution is ridiculously simple as well. Maybe somewhere in between?

[Pinga]

Amazing changes, feeling hopeful for a system that we can calculate ahead instead of trial and error in the editor. Specially excited not to have to worry about build order ever again.

Just one thing: is there any planned improvements to heat pipes? Currently they don't communicate very well how far the heat can go (which is not far at all). Which leads to a lot of trial and error in the editor. I'd rather have the same system of "one heat box" that just works than a pretend realism that you can't predict.

Regardless, SA is looking very good, can't wait.

[bobucles]

I stand corrected; what an odd choice. Considering the values of fluid, I thought it was to avoid floats entirely. I do not see any need for the fluids to be floating point numbers.

Edit: Unless, of course, that they are really integers below, and then divided by 10 or 100 for show, but I doubt it.

Why even think of using a floating point number? The very instant it drifts more than 3 significant figures, it screws the programmer (and the player) over with its endlessly drifting precision. Who wants to haul 30.0 items for a thing, and end up with 29.999999643 items so they can't do the thing? Utterly useless. Floating point has never made sense for tracking any discrete value, ever.
Pumps spit out a specific amount of fluid.
Pipes hold a specific amount of fluid.
Recipes demand inputs of specific amounts of fluid.
Recipes output specific amounts of fluid.
All the values being used are extremely discrete. Integer math is fast. If you need precision, use centi units or milli units. Easiest math in the world. If your math needs extreme levels of decimal precision, uhh don't do that. Players never notice a rounding error, except when it spits in their face.

[JigSaW]

People are still discussing "fun vs. realism" topic while i have a strong feeling it was a deliberate misdirection to distract people from the real change that was made to the game.

At the base gameplay level this change is nothing short of straight up simplification of the fluid handling. You had a flow mechanic you had to deal with and now you don't. And the realism angle was the only positive one with which you could present this change in a positive light without admitting that the whole aspect of the game is being removed. Check this forum or reddit, literally no one is saying "old pipes were better cos they were more realistic", everyone who's against this saying "old pipes were better cos they were its own logistical puzzle that's now gone".

This is a game about solving logistical puzzles, not a hardcore realistic sim. More logistical puzzles > less logistical puzzles, this is *the only* comparison that has a place to be in this conversation (or at the very least the first comparison one should care about). Don't forget that at the end of the day FFFs are marketing material that will try to present in a positive light everything that's coming.

[Svip]

I stand corrected; what an odd choice. Considering the values of fluid, I thought it was to avoid floats entirely. I do not see any need for the fluids to be floating point numbers.

Edit: Unless, of course, that they are really integers below, and then divided by 10 or 100 for show, but I doubt it.

Why even think of using a floating point number? The very instant it drifts more than 3 significant figures, it screws the programmer (and the player) over with its endlessly drifting precision. Who wants to haul 30.0 items for a thing, and end up with 29.999999643 items so they can't do the thing? Utterly useless. Floating point has never made sense for tracking any discrete value, ever.
Pumps spit out a specific amount of fluid.
Pipes hold a specific amount of fluid.
Recipes demand inputs of specific amounts of fluid.
Recipes output specific amounts of fluid.
All the values being used are extremely discrete. Integer math is fast. If you need precision, use centi units or milli units. Easiest math in the world. If your math needs extreme levels of decimal precision, uhh don't do that. Players never notice a rounding error, except when it spits in their face.

Floats can represent all integers, no problem. Floats arithmetic is about as fast (if not equally so) as integer arithmetic, since there are specific float CPU instructions. What the programmer needs to remember, is to round their floats when are done calculating. Working with two decimals in floating point numbers is usually fine.

My argument against floats for fluids, is that I don't even see the need to be that discrete with the value of fluids.

[Ultimoos]

I came here to share my support and approval for this change.

[MeduSalem]

Floats arithmetic is about as fast (if not equally so) as integer arithmetic, since there are specific float CPU instructions.

Many integer calculations take 1-2 cycles on modern x86 CPUs.
Multiply about 3-4, divisions vary a lot with ~15 cycles.

In the best cases x87 floating point Additions/Subtractions, are in the range of terrible integer calculations. About 3-4 cycles.
Multiplication are about 4-8 cycles.
Divisions are about equally with integers with 15-20 cycles.
And the rest of the x87 stuff (like trigonometry etc) you don't even want to use because they are horrendous ranging from anything 40 up to 150 cycles. You might be even better off using a fixed lookup table for that sort of stuff.

It sure depends on the processor models and how recent they are. Because on more recent ones they waste ridiculous amounts of transistors just to cut a pass out and to reduce the latency by 1-2 cycles. But even if they spend another ton of transistors floating point stuff will likely not get to integer levels of performance for some functions. It would just take ungodly amounts of space on a CPU die to make them faster.

So if you can avoid floating point stuff, it is not a bad idea to do it.

However for performance reasons there are also reasons to use floating point stuff even though they generally perform slower. The reason is the Out of Order pipelinining. When the Integer ALUs are all busy already the Instruction Scheduler would try to fill idle Floating point ALUs to do also some work. Requires some balancing where it makes sense and where it doesn't. Because neither a pure Integer nor a pure Floating point program would be utilizing a modern CPU's capabilities well.

[Svip]

Floats arithmetic is about as fast (if not equally so) as integer arithmetic, since there are specific float CPU instructions.

Many integer calculations take 1-2 cycles on modern x86 CPUs.
Multiply about 3-4, divisions vary a lot with ~15 cycles.

In the best cases x87 floating point Additions/Subtractions, are in the range of terrible integer calculations. About 3-4 cycles.
Multiplication are about 4-8 cycles.
Divisions are about equally with integers with 15-20 cycles.
And the rest of the x87 stuff (like trigonometry etc) you don't even want to use because they are horrendous ranging from anything 40 up to 150 cycles. You might be even better off using a fixed lookup table for that sort of stuff.

It sure depends on the processor models and how recent they are. Because on more recent ones they waste ridiculous amounts of transistors just to cut a pass out and to reduce the latency by 1-2 cycles. But even if they spend another ton of transistors floating point stuff will likely not get to integer levels of performance for some functions. It would just take ungodly amounts of space on a CPU die to make them faster.

So if you can avoid floating point stuff, it is not a bad idea to do it.

However for performance reasons there are also reasons to use floating point stuff even though they generally perform slower. The reason is the Out of Order pipelinining. When the Integer ALUs are all busy already the Instruction Scheduler would try to fill idle Floating point ALUs to do also some work. Requires some balancing where it makes sense and where it doesn't. Because neither a pure Integer nor a pure Floating point program would be utilizing a modern CPU's capabilities well.

I'll admit, I am not that deep into the actual performance of arithmetic CPU instructions, though I feel like I can gather that floats are generally not much worse than integers, of course, depending on the CPU, and floats tend to fair better than integers for divisions.


Source.

But I thought x87 wasn't really around anymore. I guess it still lingers on (to some extend) in i686 and amd64.

Though, again, I see no need for using floating point with fluids in Factorio.

[Eketek]

If there is a desire for a simplified system that runs fast but still does fluid flow, one thing I might suggest is to require that the entire pipe be filled completely remain so at all times, treat all inputs and outputs as applying a fixed pressure to the system, model static flows as needed (for whatever combination of consumers and producers is applying pressure to the system), and memoize the results.

EDIT: It also would be simple to take this system and implement a "hardcore" option whereby the system will happily send flow/pressure and [rate of change of flow] which are much stronger than the pipes can handle, requiring either higher quality pipes to sustain it or circuit control to moderate it (possibly have high-quality producers, consumers, and pumps apply higher pressure).

[o6dukeleto]

You say trains are OP compared to belts, but if you run a belt over 1000 tiles.....

Likewise, if you use pipes to make some sulfuric acid over such distances, you'll have to invest 100000 units of sulfuric acid to fill the pipe, which is about 30 minutes of a factory working to make your pipe work, 2000 plates, and 10000 sulfur, which is a huge waste

So the only way I could see reasonable to use hyper long pipes is to move water, but water is available everywhere

Disagree, to pipe 1000 tiles you only need to invest less than 20000 units of sulphuric acid to fill the pipe. You only need 2 pipe to ground for 11 tiles, each pipe to ground needs 100 units of sulphuric acid to be filled. This is much less than the storage tanks you would need to fill and empty a train car. Each tank being 25000 units, you would also need an additional train car also holding 25000 units. (BTW is the 30min for 100000 units, based upon a single plant? This seems like a low amount of plants if you are distributing sulphuric acid to uranium deposits... I suspect you will have more than one sulphuric acid plant by the time you are mining uranium.)

Secondly, if managed correctly, the 20000 units (or even 100000 units) to fill the pipe would be a "one time" cost -- and one time costs become negligible in the long run.

Thirdly, you would build up the sulphuric acid pipe network over time, so the one time costs are broken into bite size chunks.

Lastly, you wouldn't need any tanks or pumps or train cars, you just have to make sure you produce at least as much as you consume.

In general, the proposed solution would likely make storage tanks (except maybe for circuit network signals), pumps and fluid train cars almost obsolete if you are optimizing fluids.

[GregoriusT]

In general, the proposed solution would likely make storage tanks (except maybe for circuit network signals), pumps and fluid train cars almost obsolete if you are optimizing fluids.

Remember, the point of Trains is not that you get more Fluid throughput, its so your Base is more modular and you dont need to put extra effort into laying a pipe in the middle of nowhere, since you can just reuse your Cargo Train Network. The CURRENT Fluid system is perfectly fine for Oil and Acid pipelines like yours, and people still use Trains for their OTHER benefits, so do not call them obsolete for no reason.

And a Storage Tank with a Pump leading into your Consumer Pipe will make a LOT of sense now, since the Pump when paired with a Tank will allow for a higher rate than the Tank alone. This is likely one of those hidden NEW emerging mechanics that the Devs mentioned in the FFF!

[Dogfood]

This adds far more realism than it removes. I don't like how the flow thing existed and became more important than other real things.
1) Pumps wouldn't evenly flow out of junctions, now they do, just like real life
2) Before pumps at the back of a system wouldn't push the rest of the fluids along, now it does, just like real life.
3) pumps are now no-longer needed every 20 meters... just like real life
4) pipes used to flow back and forth before equilibrium, this is NOT like real life, there's too much friction for this in real life. Once it's evenly distributed it sits there.

Done a lot of engineering for pipework, have you? Because none of these are really true about real-life piping. Have you taken a single fluid mechanics class in your life?

[bobucles]

Floats can represent all integers, no problem. Floats arithmetic is about as fast (if not equally so) as integer arithmetic, since there are specific float CPU instructions. What the programmer needs to remember, is to round their floats when are done calculating. Working with two decimals in floating point numbers is usually fine.

My argument against floats for fluids, is that I don't even see the need to be that discrete with the value of fluids.

Well. No one never NEEDS accuracy, until they do. Integers always do it, always at the precision you need, and behave the way you expect. Floats don't. There are plenty of hilarious videos showing the consequences of misusing floats. A cute one is how minecraft boats can fall be safe most of the time, yet die from very specific heights, due to floating point oversights.

Floats can behave like integers, by tying them down with rules that force them into discrete behavior. But that's the "goes in the square hole" solution, it's still the wrong shape in the first place.

Medusalem has a good point. The main reason to misuse floating point, is to be a cheeky bugger who's distributing heat/load on the CPU. The transistors are there, so may as well use them, right? But I dunno if today's CPUs really have "spare transistors" per se. They are vastly over provisioned with tools and gadgets for what they can do, but are constrained by a heat/electricity budget instead. So which is really the cheekier option, that's always going to be a moving target. Best to keep things simple.

[PotatoGolem]

This adds far more realism than it removes. I don't like how the flow thing existed and became more important than other real things.
1) Pumps wouldn't evenly flow out of junctions, now they do, just like real life
2) Before pumps at the back of a system wouldn't push the rest of the fluids along, now it does, just like real life.
3) pumps are now no-longer needed every 20 meters... just like real life
4) pipes used to flow back and forth before equilibrium, this is NOT like real life, there's too much friction for this in real life. Once it's evenly distributed it sits there.

Done a lot of engineering for pipework, have you? Because none of these are really true about real-life piping. Have you taken a single fluid mechanics class in your life?

lol for real, this persons never had to deal with a water hammer blowing a coupling

[Lithane]

Still, considering that machines, pumps and offshore pumps (I assume) are still limited by how much they produce/move, pipe segments will - as indicated - not immediately fill. This limits how much machines can draw from the pipe segment (as indicated in the FFF). So even for larger bases, you'll still need several pipes (with the same fluid) running alongside one another to achieve the throughput you are looking for.

That's the thing with the new system though, the pipes are throughput unlimited and just one "segment". There is no limit to what a single pipe can carry, you just jam more input in and get more output. It's literally the same system as electricity, you should only need one pipe for your entire base for each liquid. If you want to see where exactly they state this in the FFF it's right above the image captioned "It just works™." where they state "There is no longer a realistic fluid "flow" through pipes; fluid pushed to a segment will be immediately available at any point along a segment. This is the "nuclear electric-network type solution" that was discussed in previous FFFs. The result is that pipes "just work" and you almost never have to worry about throughput."

So yup, they turned pipes into the electric grid system, completely pointless. Storage tanks are now functionally the same as an accumulator and anything that is connected to the grid can receive as much of whatever is available on the grid as it can take.

[Svip]

Floats can represent all integers, no problem. Floats arithmetic is about as fast (if not equally so) as integer arithmetic, since there are specific float CPU instructions. What the programmer needs to remember, is to round their floats when are done calculating. Working with two decimals in floating point numbers is usually fine.

My argument against floats for fluids, is that I don't even see the need to be that discrete with the value of fluids.

Well. No one never NEEDS accuracy, until they do. Integers always do it, always at the precision you need, and behave the way you expect. Floats don't. There are plenty of hilarious videos showing the consequences of misusing floats. A cute one is how minecraft boats can fall be safe most of the time, yet die from very specific heights, due to floating point oversights.

I don't disagree, I generally avoid floats entirely. If I truly need decimal arithmetic, I look for fixed numbers instead, even though they are slower. But floats themselves are not entirely without merit, programmers just need be aware of all their pitfalls. And usually, being aware of the pitfalls is when you chose to use integers instead.