Friday Facts #416 - Fluids 2.0
-
- Manual Inserter
- Posts: 2
- Joined: Wed Nov 23, 2022 9:08 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.
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.
Re: Friday Facts #416 - Fluids 2.0
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
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
My color birthday was May 2nd 2020 - Thank you Enchroma
- GregoriusT
- Filter Inserter
- Posts: 315
- Joined: Wed Apr 10, 2019 6:42 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.
I really want to run a non-underground pipe for once without feeling like doing everything wrong.
Don't underestimate Landmines!
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
Re: Friday Facts #416 - Fluids 2.0
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.GregoriusT wrote: ↑Sat Jun 22, 2024 11:17 amUhhh 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.Svip wrote: ↑Sat Jun 22, 2024 11:09 amI 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.FasterJump wrote: ↑Sat Jun 22, 2024 10:30 amHow 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.
Edit: Unless, of course, that they are really integers below, and then divided by 10 or 100 for show, but I doubt it.
-
- Inserter
- Posts: 28
- Joined: Fri Feb 12, 2016 12:23 am
- Contact:
Re: Friday Facts #416 - Fluids 2.0
Maybe the FFF should have said Realism instead of Fun?Succ-Orange wrote: ↑Sat Jun 22, 2024 12:01 pmThis 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.
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?
Re: Friday Facts #416 - Fluids 2.0
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.
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.
Re: Friday Facts #416 - Fluids 2.0
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.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.
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.
Re: Friday Facts #416 - Fluids 2.0
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.
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.
Last edited by JigSaW on Sat Jun 22, 2024 1:27 pm, edited 1 time in total.
Re: Friday Facts #416 - Fluids 2.0
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.bobucles wrote: ↑Sat Jun 22, 2024 1:12 pmWhy 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.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.
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.
My argument against floats for fluids, is that I don't even see the need to be that discrete with the value of fluids.
Re: Friday Facts #416 - Fluids 2.0
I came here to share my support and approval for this change.
Re: Friday Facts #416 - Fluids 2.0
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.
Re: Friday Facts #416 - Fluids 2.0
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.MeduSalem wrote: ↑Sat Jun 22, 2024 1:54 pmMany 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.
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.
Re: Friday Facts #416 - Fluids 2.0
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).
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).
Last edited by Eketek on Sat Jun 22, 2024 3:27 pm, edited 2 times in total.
-
- Inserter
- Posts: 28
- Joined: Fri Feb 12, 2016 12:23 am
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.)gaelyte wrote: ↑Fri Jun 21, 2024 4:01 pmYou 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
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
- Filter Inserter
- Posts: 315
- Joined: Wed Apr 10, 2019 6:42 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
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.o6dukeleto wrote: ↑Sat Jun 22, 2024 3:21 pmIn 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.
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!
Last edited by GregoriusT on Sat Jun 22, 2024 4:01 pm, edited 1 time in total.
Don't underestimate Landmines!
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
Biters bite, Spitters spit, Spawners spawn and Worms... worm? - No, they throw their vomit! They even wind up to directly hurl it at you! friggin Hurlers...
Re: Friday Facts #416 - Fluids 2.0
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?Succ-Orange wrote: ↑Sat Jun 22, 2024 12:01 pmThis 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.
Re: Friday Facts #416 - Fluids 2.0
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.Svip wrote: ↑Sat Jun 22, 2024 1:24 pmFloats 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.
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.
-
- Manual Inserter
- Posts: 2
- Joined: Fri May 17, 2024 5:57 pm
- Contact:
Re: Friday Facts #416 - Fluids 2.0
lol for real, this persons never had to deal with a water hammer blowing a couplingDogfood wrote: ↑Sat Jun 22, 2024 4:01 pmDone 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?Succ-Orange wrote: ↑Sat Jun 22, 2024 12:01 pmThis 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.
Re: Friday Facts #416 - Fluids 2.0
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."Svip wrote: ↑Sat Jun 22, 2024 4:27 amStill, 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.
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.
Re: Friday Facts #416 - Fluids 2.0
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.bobucles wrote: ↑Sat Jun 22, 2024 5:25 pmWell. 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.Svip wrote: ↑Sat Jun 22, 2024 1:24 pmFloats 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.