Gases/Liquids being destroyed

[Octyabr]

Important:

Since the update #207380 fixed pumps I had to do everything again to check if it were fixed.

Playing around with water and also with thermal regulators I've noticed that some amount gets lost somewhere somehow with every single setup I've made.

Trying to narrow down the variables, I've made the simplest setup: transport a set amount of oxygen and water.

Initial Setup (Control Group):

Spoiler

With the help of the paint tool I emptied both left rooms, and filled the right ones with 2kg of oxygen per tile and 1000kg of water (instead I got 1000.675kg)
The first odd thing I've noticed: the upper room is uniformly filled with oxygen, but as you can see in the water room, the lower tiles contained a bigger amount as if the water were more compressed there.

Starting amounts:

• Oxygen: (2kg per tile) * (20 tiles) = 40kg total
• Water: (970.9kg per tile) * (5 tiles) + (1000.9kg per tile) * (5 tiles) + (1010.9kg per tile) * (5 tiles) + (1020.0kg per tile) * (5 tiles) = 20013.5kg total

The Result:

Spoiler

After some time both right rooms where emptied, a lot longer in the case of the water, as expected.

End amounts:

• Oxygen: (1.3514kg per tile) * (20 tiles) = 27.028kg total
• Water: (501.7kg per tile) * (5 tiles) + (1000.0kg per tile) * (5 tiles) + (1010.0kg per tile) * (5 tiles) + (1020.1kg per tile) * (5 tiles) = 17659kg total

Comparison:

• Oxygen: 40kg before, 27.028kg after = 12.972kg lost (32.43%)
• Water: 20013.5kg before, 17659kg after = 2354.5kg lost (11.76%)

Setup 2 (Bridges):

Spoiler

End amounts:

• Oxygen: (1.2625kg per tile) * (20 tiles) = 25.250kg total
• Water: (573.9kg per tile) * (5 tiles) + (1000.0kg per tile) * (5 tiles)  = 7869.5kg total

Comparison:

• Oxygen: 40kg before, 25.250kg after = 14.750kg lost (36.88%)
• Water: 20013.5kg before, 7869.5kg after = 12144kg lost (60.68%)

Setup 3 (Valves):

Both valves set to half their max capacity.

Spoiler

End amounts:

• Oxygen: (1.2516kg per tile) * (20 tiles) = 25.032kg total
• Water: (898.6kg per tile) * (5 tiles)  = 4493kg total

Comparison:

• Oxygen: 40kg before, 25.032kg after = 14.968kg lost (37.42%)
• Water: 20013.5kg before, 4493kg after = 15520.5kg lost (77.55%)

Setup 4 (Filters):

The first result was made accepting oxygen and water (middle red output) and the second result accepting anything else. (hydrogen and mercury)

Spoiler

Filter in:

End amounts:

• Oxygen: (1.273kg per tile) * (20 tiles) = 25.46kg total
• Water: (323.5kg per tile) * (5 tiles)  = 1617.5kg total

Comparison:

• Oxygen: 40kg before, 25.46kg after = 14.54kg lost (36.35%)
• Water: 20013.5kg before, 1617.5kg after = 18396kg lost (91.92%)

Filter out:

End amounts:

• Oxygen: (1.2481kg per tile) * (20 tiles) = 24.962kg total
• Water: (244.2kg per tile) * (5 tiles)  = 1221kg total

Comparison:

• Oxygen: 40kg before, 24.962kg after = 15.038kg lost (37.6%)
• Water: 20013.5kg before, 1221kg after = 18792.5kg lost (93.9%)

To do:

Test increasing the amount of:

• Pipes
• Vents
• Pumps

[Alia]

Moar science needed!  

[DrAg0]

Couple of questions that pop up in my head.

Since when can gas pumps suck out every gas in a room and produce a full vacuum
Since when can Gas Outputs dump gas in high pressure.

Another thing with your setup.
Why did you run pipes that much in the open? To prevent measure failures it usually is best to minimize the chance of measure failures to begin with.
It is possible (and thinkable) that there wasn't as much water/oxygen in the right tanks to begin with as the pump and the pipes block the space where the oxygen/water could be and all visible measurementsyou have taken are only visual bugs.

[Vilda]

13 minutes ago, DrAg0 said:

It is possible (and thinkable) that there wasn't as much water/oxygen in the right tanks to begin with as the pump and the pipes block the space where the oxygen/water could be and all visible measurementsyou have taken are only visual bugs.

No for the pipes, those are "background" objects. The pumps could be screwing the amounts though.

[Vilda]

I would suspect Vents as the culprit, there seems to be something wrong with their output, especially dealing with small amounts. For example when water was dripping it just spread in minuscule amounts and basically was the same - perhaps rounding error spread?I have a setup in mind I'll try in the evening.

[Saturnus]

30 minutes ago, Vilda said:

No for the pipes, those are "background" objects. The pumps could be screwing the amounts though.

Easy fix is to repeat it with identical set ups in both chambers, and only power one or the other side. Then you can also reverse the process over and over and see if there is indeed a loss over the long term.

I have a sneaking suspicion that there might actually be a loss due to the material used. I've had water tanks and pressurized steam tanks built out of sandstone tiles fail several times, so I think sandstone tiles actually absorbs some water and air and eventually crack.

Which btw, is a way to make sand to repIenish that consumable resource I may add. Just need to figure out a system that reliably cracks and break the sandstone tiles into sand. 

[Vilda]

Okay, got to it a bit sooner. I've setup a quick and dirty combo - Bio Distiller -> Water Purifier -> pipes + Vent -> small empty tank.

Contrary to my initial suspicion, there was no water loss on Vent. There was actually no water loss in this setup at all, what went in, went into a 2x2 tank. Putting aside that output of Distiller is looooooow with how much slime it can have in it at one time.

Next I have in mind water dripping on a diagonal surface, there was a weird spread and water disappearing in my last game when I popped a contaminated water bubble to lead it into a tank.

[Vilda]

Well, crash and burn again.

In my case the numbers match, it just seems to be a graphical presentation issue. When liquid falls over the edge, especially longer diagonal it looks like there is a lot of water, when in reality there is maximum about 3kg of water. Compared to a full tile of about 1000 kg. When it gets to a flat surface it levels up and looks like it's disappearing.

Animation of Vent is "out of sync" too, for actual traveling water levels one must switch to liquid view.

So in conclusion, no water lost while traveling over a surface or out of Vent, just graphical presentation issue.

Lots of water is though lost when you build an object in it. Wall certainly, pump maybe not, water level was too low when I built that one.

[Saturnus]

Building a tile is an excellent way of removing a contaminated water spot in an otherwise clean tank. But it destroys the water by doing so you might wanna take that into consideration.

[dunny]

How much water is still in the pipe?

[Octyabr]

5 hours ago, DrAg0 said:

Since when can gas pumps suck out every gas in a room and produce a full vacuum

It's intended, since my setup system is very small it happens very quickly, given enough time any room can be emptied.

5 hours ago, DrAg0 said:

Since when can Gas Outputs dump gas in high pressure.

Intended too, but in real scenarios (bigger rooms thus longer times pumping) they bug long before that, even with pressures as low as 160g/t. Again due to my system being very small, the transfer is over before the vents bug.

5 hours ago, DrAg0 said:

Why did you run pipes that much in the open?

For a couple of reasons:

Aesthetically pipes look nice.
I wanted to make the shortest possible path between inputs and outputs

5 hours ago, DrAg0 said:

It is possible (and thinkable) that there wasn't as much water/oxygen in the right tanks to begin with as the pump and the pipes block the space where the oxygen/water could be and all visible measurementsyou have taken are only visual bugs.

The rooms were constructed first, any debris wiped out (manually by the way, since back then I didn't found the insta-build feature) and then all rooms were completely emptied and the right ones filled. Then I proceeded to check every cell, this is how I've found that lower water tiles "compress" due to the weight of the tiles above.

22 minutes ago, dunny said:

How much water is still in the pipe?

Once the right rooms are empty, the pumps continue working until the pipes are also empty.

[Estece]

It's common math problem for inexperienced programers to use floats numbers math.

It's common performance problem for inexperienced programers to use #@!$% unity engine.

To avoid bugs like this use Your's brain and learn proper programing practices and floating point number mathematics.

[Michi01]

Not sure if this is related but when I built a liquid pipe bridge only half of what went into the bridge came out on the other side. Maybe it wasn't displayed properly I'm not sure.

[Cyberboy2000]

2 hours ago, Estece said:

It's common math problem for inexperienced programers to use floats numbers math.

It's common performance problem for inexperienced programers to use #@!$% unity engine.

To avoid bugs like this use Your's brain and learn proper programing practices and floating point number mathematics.

That is not how floats work. Floating point mathematics is very precise when dealing with numbers on this scale, it is only imprecise when mixing large and small numbers.

[Saturnus]

5 hours ago, Octyabr said:

Then I proceeded to check every cell, this is how I've found that lower water tiles "compress" due to the weight of the tiles above.

 

Yeah, that's how physics works. One tile is 1x1m, so one 1m3. In real life water pressure increase 10% per meter depth, so the numbers seem to reflect that quite accurately.

Air pressure however doesn't change much with small increases in elevation, and it's not a linear curve but it takes roughly 1000m difference in height to get 10% higher or lower air pressure.

[ShaTiK]

Whatever the case may be - that's a hell of a loss. To loose 30% of oxygen and 15% of water for no reason is insane. Especially considering that right now there is no endless sustainability 

[DockLazy]

36 minutes ago, Cyberboy2000 said:

That is not how floats work. Floating point mathematics is very precise when dealing with numbers on this scale, it is only imprecise when mixing large and small numbers.

That guy was rude but he isn't wrong. Truncation errors aren't the only thing you have to worry about. Especially when running a simulation where errors can accumulate quickly.

What ever the cause 30% loss is way to high, or 99% in some cases when draining a lake. Even single digit losses make things like air conditioning your base unviable.

 

 

[Octyabr]

9 hours ago, Michi01 said:

Not sure if this is related but when I built a liquid pipe bridge only half of what went into the bridge came out on the other side. Maybe it wasn't displayed properly I'm not sure.

I'm gonna test that.

9 hours ago, Estece said:

It's common math problem for inexperienced programers to use floats numbers math.

It's common performance problem for inexperienced programers to use #@!$% unity engine.

To avoid bugs like this use Your's brain and learn proper programing practices and floating point number mathematics.

That's why I never use them for storing, only integers for me.

I'd like to know a little more about your opinion on the Unity engine.

[Wayland]

10 hours ago, Saturnus said:

Yeah, that's how physics works. One tile is 1x1m, so one 1m3. In real life water pressure increase 10% per meter depth, so the numbers seem to reflect that quite accurately.

Air pressure however doesn't change much with small increases in elevation, and it's not a linear curve but it takes roughly 1000m difference in height to get 10% higher or lower air pressure.

That's not correct. Pressure increases rapidly with depth, but water, like all non-gas, is actually nearly incompressible. Yes, in gases, (or at least ideal gases) pressure and density are directly related. According to Wikipedia, at 4km depth, water's density only increases by 1.8%. The behaviour in the game seems to be a bug, or at least inconsistent with reality.

[Saturnus]

3 hours ago, Wayland said:

That's not correct. Pressure increases rapidly with depth, but water, like all non-gas, is actually nearly incompressible. Yes, in gases, (or at least ideal gases) pressure and density are directly related. According to Wikipedia, at 4km depth, water's density only increases by 1.8%. The behaviour in the game seems to be a bug, or at least inconsistent with reality.

Absolutely correct. And then not actually. Note that I specifically wrote pressure, and not density.

I suspect that when the game lists density, they actually mean pressure in order to have a game mechanics for compressive strength of materials.

I should have noted that I was trying to reverse engineer the game mechanics. My bad. And glad you caught me on that.

[Wayland]

23 hours ago, Saturnus said:

8 hours ago, Saturnus said:

Absolutely correct. And then not actually. Note that I specifically wrote pressure, and not density.

I suspect that when the game lists density, they actually mean pressure in order to have a game mechanics for compressive strength of materials.

I should have noted that I was trying to reverse engineer the game mechanics. My bad. And glad you caught me on that.

Yes, you said pressure, but in the image posted it's showing that there's a different AMOUNT of water in the bottom blocks than the top blocks, which is density. What it's doing in the game is actually -removing- water from the top blocks and stuffing them into the bottom blocks. The materials (presumably you mean solids) don't exhibit this behaviour and in fact, don't seem to model internal pressure (like, the pressure of the solids above them) at all. But yes, there's some sort of mechanic that allows certain types of materials (tiles, but not natural walls) to blow-out if there's too much liquid pressure in them but I suspect that 'pressure' doesn't actually exist in the game, only 'density'.

So here's a proposed model for how this might be working:

• There's no 'pressure' at all, at least not as a calculated or stored intrinsic property of the fluid in a block
• Instead of pressure, the 'capacity' (in kg) of a fluid (liquid or gas) increases based on if there's another fluid block above it and what that block's capacity is.
• To determine if a tile wall should fail, it compares the amount (kg) of a fluid next to it against a baseline and uses that as a stand-in for pressure.
• So if you have a deep well, the bottom block might have 1500kg of water instead of a baseline of 1000kg and the game would compare 1500kg to the thickness and strength of the adjacent wall to determine if the wall fails.
• Similarly, if you're going with gases, even if a pump at the bottom is in at high pressure (say, 5kg of Oxygen) and the top is at only half that (2.5kg) the vent will have a fixed limit (is it 2kg?) and will refuse to deliver gas, even though the base of the pump is much higher density than the top.
• So, the result of this proposed model would be that because there is not actually 'pressure' in the game, only a computed capacity, the game could not have 'vessel failure' work for liquids unless the game allowed liquids to be compressible.
• A benefit to the developers to have a model like this could potentially be a way to avoid tiles from having to make any calculations on tiles that are not directly adjacent.
• This would also indirectly result in the behaviour that we see that causes gases and pressure to dissipate SO SLOWLY.

[Risu]

Had to check the code but there actually is no loss in material between pump and vent.
Going into buildings however... explained that in a bug report that I suspect to have been ignored.
 

[Drizzt321]

23 hours ago, DockLazy said:

That guy was rude but he isn't wrong. Truncation errors aren't the only thing you have to worry about. Especially when running a simulation where errors can accumulate quickly.

What ever the cause 30% loss is way to high, or 99% in some cases when draining a lake. Even single digit losses make things like air conditioning your base unviable.

Not solely truncation issues, but precision issues. 1.0 float is NOT actually always 1.0 in representation. See http://floating-point-gui.de/basic/ for a lot more details. It's an issue, but can be dealt with. Use Decimal type of some sort with a fixed number of digits, that might work.

 

[Octyabr]

Pro tip: avoid filters, bridges and valves.

[Risu]

13 hours ago, Octyabr said:

Pro tip: avoid filters, bridges and valves.

To be more precise, avoid letting partial fluid blobs merge where the combined mass overflows.
There is a known bug (with a known fix) and I hope the devs notice it soon.