What is the cause of infinite liquid compression mass increase?

[Zarquan]

Has there been an exploration of the bug where the mass of an infinitely compressed liquid starts increasing dramatically?

I am curious about what causes it and how to circumvent it.  Often, exploring the cause of these problems results in a fix, and I would love to be able to use infinite liquid compression without it creating mass.

[sakura_sk]

Doors opening and closing on top of liquids creates the problem. No door, no problem 

[Zarquan]

50 minutes ago, sakura_sk said:

Doors opening and closing on top of liquids creates the problem. No door, no problem 

If doors are a cause, they are not the only cause.  It happens when you just have a liquid vent on a less dense liquid too, similar to this screenshot from a Francis John video, where the water in that one tile is more than it could be if it was filling with water since the beginning of the colony.

[sakura_sk]

I assume this still exists and plays a factor at duplicating liquids

https://forums.kleientertainment.com/forums/topic/130206-construct-your-very-own-homemade-2kgs-geyser-hopefully-to-soon-be-patched-away/

[blakemw]

I tried looking into it and easily reproduced it.

Make a 2x2 blob of compressed water using debug, say 1,000,000 kg of water per tile (exact amount doesn't matter too much as long as it's not too much bigger than 16,000,000 which is when floating point calculation kicks in seriously) while trickling in new water via a vent submerged in crude oil or whatever.

Let the simulation run for a while. For a while the water will just compress down, as the game tries to make the bottom tile 1% larger than the top tile. Then at some point, abruptly some of the cells will transfer I think 25% (or perhaps 12.5% each up and sideways). Sometimes this calculation is done correctly and the final sum of mass is the same, but sometimes, I think due to the Vent adding new mass, the cell which donates the mass doesn't lose its 25%, so the system gains 25% of a cell. This doesn't happen all of the time but does happen often enough to be readily observed with a few trials.

The "25%" thing makes me think it's likely related to the "home made geyser" exploit, probably related to the game having a tile undergo division but keeping its original mass if new liquid is being merged into it.

Anyway with the system occasionally gaining 25% of a cell mass, this easily explains how it can grow so big. Exponential growth and all.

In the FJ screenshot the system is capping out at somewhere around 16,000,000, this is because at this point the 32 bit floating point calculation are so imprecise that the added water from the Vent is not actually increasing the mass of the tile (for instance with 32 bit floats, 17,000,000 + 1 = 17,000,000). Once the tiles can no longer gain new mass from the Vent, they'll stop sharing mass.

[Zarquan]

4 hours ago, blakemw said:

I tried looking into it and easily reproduced it.

Make a 2x2 blob of compressed water using debug, say 1,000,000 kg of water per tile (exact amount doesn't matter too much as long as it's not too much bigger than 16,000,000 which is when floating point calculation kicks in seriously) while trickling in new water via a vent submerged in crude oil or whatever.

Let the simulation run for a while. For a while the water will just compress down, as the game tries to make the bottom tile 1% larger than the top tile. Then at some point, abruptly some of the cells will transfer I think 25% (or perhaps 12.5% each up and sideways). Sometimes this calculation is done correctly and the final sum of mass is the same, but sometimes, I think due to the Vent adding new mass, the cell which donates the mass doesn't lose its 25%, so the system gains 25% of a cell. This doesn't happen all of the time but does happen often enough to be readily observed with a few trials.

The "25%" thing makes me think it's likely related to the "home made geyser" exploit, probably related to the game having a tile undergo division but keeping its original mass if new liquid is being merged into it.

Anyway with the system occasionally gaining 25% of a cell mass, this easily explains how it can grow so big. Exponential growth and all.

In the FJ screenshot the system is capping out at somewhere around 16,000,000, this is because at this point the 32 bit floating point calculation are so imprecise that the added water from the Vent is not actually increasing the mass of the tile (for instance with 32 bit floats, 17,000,000 + 1 = 17,000,000). Once the tiles can no longer gain new mass from the Vent, they'll stop sharing mass.

So you think it's the vent causing it combined with the weird water fluctuations that exist to push water up, with the root problem being due to miscalculating cell division when mass is added from the vent.  Perhaps it is related to the fact that it is probably attempting to make a tile using an approach similar to the EZ-Bead method.  Both vents are on tiles, so does this happen if the crude oil were replaced with crude oil with petroleum on top with the vent in the petroleum?  Or does this also try to create a bead?

I ran a similar trial for a while and nothing happened, but I realized my build was not the build Francis John used.  I used doors rather than airflow tiles.  I will try it again for longer, but perhaps this can give some insight. 

EDIT: Nevermind, I just was unlucky or I wasn't in a state where it would trigger.  It didn't happen in my trial in over 50,000 kg pumped, but then it happened within 17500 kg pumped this time.  So unless it requires a huge mass to happen (I was using a smaller amount in my trial).  Perhaps it is just more frequent when the mass is larger, which would make sense because it would likely do the shooting up thing more often, which would make this possibly more than exponential.  I do see more of the shooting up at 1,000,000 kg/tile than I do at 20,000 kg/tile, for example, so perhaps you have to get lucky with the ticks.

 

[Zarquan]

I can confirm that it is NOT a weird interaction with the vent, as the setup below also had it, and a lot faster than the vent one, like it happens within seconds (unless I just got lucky).  I suspect the rapidity of this one is due to the fact that water is being added to the tile every tick rather than every second, increasing the chance of it happening in any given second.  But it does mean escher waterfalls do not avoid this problem.  Next up is airflow condensation teleportation.

[blakemw]

1 hour ago, Zarquan said:

Perhaps it is related to the fact that it is probably attempting to make a tile using an approach similar to the EZ-Bead method.  Both vents are on tiles, so does this happen if the crude oil were replaced with crude oil with petroleum on top with the vent in the petroleum?  Or does this also try to create a bead?

I'm pretty sure making a stack of crude oil and petroleum would change nothing.

Trying some other things:

If using a "gas immersed ceiling Vent" rather than a "liquid immersed floor Vent" it seems that mass duplication is much less common. My speculation is that this is because the drop falls until it hits liquid, and then merges into that liquid tile. Now the critical thing here, is that I think for the mass duplicating split to happen the bottom tile has to be more massive than the top tile, this happens easily when new mass is being added to the bottom tile, because gravity pressurization and the vent are working together to increase the mass of the bottom tile. But when the Vent is above, it's increasing the mass of the top tile, so the Vent and gravity are at odds and it takes much longer for the bottom tile to become more massive than the top tile. The mass duplication glitch can still be observed to happen (sometimes) as the bottom tile exceeds the top tile in mass, but it takes much longer.

The trick where steam is condensed in an airflow tile and then teleports up into an infinite storage, does not seem to cause any mass duplication, or at least I couldn't trigger any. The  code the game uses for merging the liquid must be different in this case.

Mashing water with Mechanical Airlocks for ages didn't seem to trigger any mass duplication, though it did very rarely cause some mass deletion even though it shouldn't have according to the understood rules of how liquid is pushed out of mechanical airlocks. So I think mechanical airlock based compression shouldn't be prone to mass duplication, though it probably does cause some mass deletion.

[Zarquan]

21 minutes ago, blakemw said:

The trick where steam is condensed in an airflow tile and then teleports up into an infinite storage, does not seem to cause any mass duplication, or at least I couldn't trigger any. The  code the game uses for merging the liquid must be different in this case.

My steam condenser-teleportation compressor just triggered the effect.  It teleports the liquid in to the chamber by condensing it in an airflow tile below.

Another question is does anything similar happen with gases.  Like, if I add steam to a room in a similar manner, does it get duplicated?  My thinking is that gases don't.

Additionally, this would also imply that a setup like the one below would not have this problem due to the fact that the liquid is confined to one tile, but it does limit the possible output.  You could get 2 pumps to pump it theoretically.

The next step is trying a purely horizontal room and purely vertical room.  I could construct a scalable room in either configuration  Or perhaps add in the liquid in that configuration and have it join a larger reservoir.

21 minutes ago, blakemw said:

I'm pretty sure making a stack of crude oil and petroleum would change nothing.

I would agree, that was based on the now-disproven premise that it is in anyway related to EZ-Bead's way of a vent on a tile forces a tile of water to appear.

 

 

[Zarquan]

@blakemw I don't think its related to the vent or adding liquid.  I created a very simple mechanism that is just the liquid and it also multiplied:

 

[hydrotoast]

Excellent intuition that you both have. I can contribute what I know regarding prior work on liquid duplication as well as a model of the isolated liquid mechanics to identify the duplicating cuplrit.

Relevant work.

This appears to be a variation of the known liquid duplication bug which involves two distinct liquids. The underlying cause is given by blakemw's intuition.

10 hours ago, blakemw said:

Sometimes this calculation is done correctly and the final sum of mass is the same, but sometimes, I think due to the Vent adding new mass, the cell which donates the mass doesn't lose its 25%, so the system gains 25% of a cell. This doesn't happen all of the time but does happen often enough to be readily observed with a few trials.

There are several mechanics that cause mass flow and when there are simultaneous inflow and outflow, we observe forms of liquid duplication. To review the bug linked, the isolated mechanics are:

1. target liquid as a tile (not as droplets from a vent), so it interacts with adjacent tiles;
2. target liquid falling, so 100% outflow down;
3. an opposing, compressible liquid (i.e. smaller mass), so compression occurs with 1/8 outflow (unbounded) from the target liquid;
4. the opposing liquid compresses into a piston (i.e. larger mass than the outflow), so decompression occurs with 1/8 inflow (unbounded) into the target liquid;

The bug occurs when the simultaneous outflow exceeds 100%, e.g. the full mass of the target liquid falls while compressing the opposing liquid(s) for an additional 1/8 outflow per direction.

Background.

For the duplication you observe in infinite storage, we can identify the isolated mechanics from Zarquan's intuition.

6 hours ago, Zarquan said:

The next step is trying a purely horizontal room and purely vertical room

For concrete numbers, there are only five element properties (see the {solid, liquid, gas}.yaml) we are interested in for both horizontal and vertical flow mechanics in the absence of exceptional behavior (e.g. multiple element compression and tension mechanics, which do not apply here).

1. minHorizontalFlow. The minimum horizontal flow with 1 cell in 1 tick.
2. speed (viscosity). The max flow with 1 cell in 1 tick.
3. minVerticalFlow. The min vertical flow with 1 cell in 1 tick.
4. maxCompression. The compression rate of vertically stacked liquids.
5. maxMass. The maximum mass before before additional mass is buried (solid) or decompressed (liquid).

For reference, consider the properties for water.

• minHorizontalFlow = 0.01 kg
• speed (viscosity) = 125 kg
• minVerticalFlow = 0.01 kg
• maxCompression = 1.01
• maxMass = 1000 kg

Based on these properties, we can define three isolated mechanics for liquids:

1. Horizontal flow. A bounded outflow with mass between [minHorizontalFlow, speed] determined by properties (1, 2).
2. Vertical flow (decompression). A conditional outflow with mass between [minVerticalFlow, infinite) determined by properties (3, 4, 5; does not include 2, so there is no upperbound)
3. Diffusion. A flow between tiles with the same element to approach static equilibrium (exact bounds unknown [^1]) known with outflow proportional to 1/4 mass.

Experimental direction.

Now, let us consider a single, compressed liquid (e.g. 8 t) in a control volume as three cases: horizontal tubes (1-tile high), vertical tubes (1-tile high), and rectangular rooms.

1. Horizontal tubes. The liquid should have outflows between [minHorizontalFlow, speed]. For water, we will primarily observe maximum outflows of 125 kg / tick. Note that the maximum horizontal outflow speed is relabeled as viscosity in-game (do not interpret this parameter as true viscosity as in reality).  These models reach static equilibrium due to the bounded flows.
2. Vertical tubes. Consider placing the mass to start by falling from the top for the best interpretation. The mass will not decompress until it reaches the bottom of the tube. Upon reaching the bottom of the tube, the mass will outflow vertically upwards [^2]. These models reach static equilibrium similar to unloading a compressed spring.
3. Rectangular rooms. Consider the infinite storage square that you have been experimenting with. A rectangular room experiences both types of mechanics simultaneously, which is often observed as "turbulent". If we observe horizontal flows on a row, they should be multiples of speed (125 kg for water). If we observe vertical flows, there is a gradient with the greatest mass flow from the bottom (c.f. blakemw observes in experiments with vents positioned at the top or bottom).

Continuing the discussion on rectangular rooms, we can conceive several cases of multiple outflows or multiple inflows that duplicate liquid.

Identifying duplication.

Consider an arbitrary liquid cell in the room. The potential outflows may include:

1. Horizontal outflow (left, right) with bounded outflow [minHorizontalFlow, speed]
2. Vertical outflow (up) with outflow [minVerticalFlow, infinite) if compressed
3. Diffusion (left, down, right, up) with outflow proportional to 1/4 mass

Given a starting mass and these three bounds, we may be able to determine which of these three mechanics are involved in the duplication process. If horizontal or vertical flow are duplicating, the additional mass will be a multiple of either minHorizontalFlow, speed, or minVerticalFlow. For water, these properties are minHorizontalFlow = 0.01 kg, speed = 125 kg, or minVerticalFlow = 0.01 kg. If diffusion is duplicating, the additional mass will grow exponentially as 1.25^t based on some function of the starting mass.

Since we use infinite storage, the lowerbound flows are unlikely to cause duplication. Instead, there are two interesting duplication cases:

1. if horizontal flow duplicates liquid, then it will increment additively with speed (e.g. +125 kg / duplication with water);
2. if diffusion duplicates liquid, then it will grow exponentially at a rate proportional to 1/4 mass;

I am interested in seeing if your experiments exhibit either of these growth behaviors.

Footnotes.

[1] The bounds are challenging to prove (if they exist) since they relate to both horizontal and vertical models (i.e. a precise 2D model may be required).

[2] I am not aware of a generalized vertical flow model that precisely describes the upwards flow rate, so I cannot provide exact numbers. See work by spiderstring on discord or mathmanican on forums for attempts at models of vertical flow.

[Zarquan]

15 hours ago, hydrotoast said:

• Horizontal tubes. The liquid should have outflows between [minHorizontalFlow, speed]. For water, we will primarily observe maximum outflows of 125 kg / tick. Note that the maximum horizontal outflow speed is relabeled as viscosity in-game (do not interpret this parameter as true viscosity as in reality).  These models reach static equilibrium due to the bounded flows.
• Vertical tubes. Consider placing the mass to start by falling from the top for the best interpretation. The mass will not decompress until it reaches the bottom of the tube. Upon reaching the bottom of the tube, the mass will outflow vertically upwards [^2]. These models reach static equilibrium similar to unloading a compressed spring.

I have done 6 trials in vertical and horizontal tubes of length 115 (a kind of random number).  The initial mass in each trial is 1,000,000 kg for each of the 115 tiles.  I picked a large number of tiles to increase the chances that the event would happen as a way to narrow down the search.

1. Horizontal tube:  Even initial distibution
2. Horizontal tube:  All liquid on right (5,000,000 kg/tile in the last 23 tiles)
3. Horizontal Tube:  All liquid on the left (5,000,000 kg/tile in the first 23 tiles)
4. Vertical Tube:  Even initial distribution
5. Vertical Tube:  All liquid at the top (5,000,000 kg/tile in the top 23 tiles)
6. Vertical Tube:  All liquid at the bottom (5,000,000 kg/tile on the bottom 23 tiles)

I don't see any major distortion in the mass of water flowing horizontally. (1-3).  I doubt the problem lies in horizontal flow

Trial 4 has not yet shown mass duplication, but I am running it for an extended period of time.

Trial 5 showed instant mass growth.

Trial 6 showed absurd mass growth.  I suspect Trial 5's growth was just the fact that the mass was falling, my hypothesis is that the bug here lies in vertical expansion of high pressure water.

I will further examine alterations to trials 5 and 6 to narrow down the exact problem.

If you want, I recorded myself doing this trial, and you can watch that in the spoiler below.

Spoiler

 

 

 

 

[Zarquan]

I'm not sure what I am seeing in this smaller trial 6 experiment.  I have a 10 tile tall room with 2,000,000 kg water at the bottom.  I attempt to go frame by frame to detect the problem (pressing space and clicking the pause button simultaneously), looking at the mass of each tile in each tick.  In one the first few ticks, it seems fine.  Then, in one tick, it shoots all the way to the top and adds a bunch of mass.  I let it run after this to see if there was a second mass spike, and there was.  Whenever it does this "shooting up" thing, it increases in mass.  It also seemed to increase the mass by a constant amount, regardless of whether it had excess room or not, even in a 5 tile tall room.

I believe this shooting up is the root of this problem and might even be the whole problem, except that I can't seem to trigger it over 2 tiles.  I would love to see how its calculated and what triggers it.

[Zarquan]

I got 2 tile-shooting up to take place.  I put a tile of 500000 kg water on the bottom and 350000 kg on top of it.  However, I have not yet found a one-tick liquid duplication from this configuration.

The ratio also works with 5000 kg on the bottom and 3500 kg on the top.

With 3,000,000 kg water, the duplication happens without the shooting up I think.

[blakemw]

Funny, about a week ago I was experimenting with what I called "rapid inflation", when highly pressurized cells abruptly expand like 5 tiles up. It extremely puzzled me in particular that rapid inflation can happen both 2 tiles right and 2 tiles left in a single tick, because I'm used to liquids only expanding by 1 tile per tick. Because of simulation order it makes sense that faster expansion can happen in two directions, but not three directions. I remain very puzzled about wtf is going on.

 

I did conclude that probably bits are breaking off, dripping down, and instantly re-merging with water tiles, though I don't think that would happen if the column is confined to a single tile width.

[mathmanican]

11 hours ago, blakemw said:

I remain very puzzled about wtf is going on.

Here's a relevant link that may help. 

 

I never got around to studying two beads side by side, or stacked on top of each other, which might have led to locating the liquid duplication issues sooner (maybe).  Sound like you guys are having some fun. 

[hydrotoast]

On 1/17/2024 at 12:41 PM, Zarquan said:

I'm not sure what I am seeing in this smaller trial 6 experiment.  I have a 10 tile tall room with 2,000,000 kg water at the bottom.  I attempt to go frame by frame to detect the problem (pressing space and clicking the pause button simultaneously), looking at the mass of each tile in each tick.  In one the first few ticks, it seems fine.  Then, in one tick, it shoots all the way to the top and adds a bunch of mass.  I let it run after this to see if there was a second mass spike, and there was.  Whenever it does this "shooting up" thing, it increases in mass.  It also seemed to increase the mass by a constant amount, regardless of whether it had excess room or not, even in a 5 tile tall room.

I describe this as "vertical flow" in my notes, which distinctly occurs in high pressure liquid tiles and flows upwards without a constant upperbound. To consolidate the terms describing this phenomena:

• "vertical flow" hydrotoast
• "rapid inflation" @blakemw
• "high pressure liquid expansion" @mathmanican
• "liquid stacking" spiderstring (Discord, from memory)

This phenomena has a few peculiar behaviors that make it challenging to analyze. For example, experiments on liquid merging by @Kastrella show that the behavior follows an alternating simulation (occurs every other tick, which varies by game speed and may vary per machine) [1]. For the context of vertical flow, I have reformulated the experiment to illustrate the alternating simulation. See the spoiler below.

Spoiler

We have four vertical tubes with height = 10. Each tube is initialized with the same high-pressure mass 2000 t with increasing tick offset:

• (+3 ticks) for tube A to expand +3 times before tube (D)
• (+2 ticks) for tube B to expand +2 times before tube (D)
• (+1 ticks) for tube C to expand +1 times before tube (D)
• (+0 ticks) for tube D

Observe that the instantaneous vertical flow has two distinct behaviors:

• vertical flow occurs at a finite distance 5-tiles away
• only 3/4 tube offsets trigger vertical flow, which cycle with the simulation

To rigorously test deterministic behavior, we must technically test at 4 contiguous tick offsets at 1x speed (maybe more if there other mechanics involved). On Kastrella's PC, the period is 48 ticks, so it may also vary per machine. Note that this alternating simulation behavior also appears in gas effusion (expanding freely in a vacuum). Generally, the behavior appears to occur when a combination of vertical flow and horizontal flow merge (or wherever 2D diffusion is involved).

On some configurations, 2/4 tubes will synchronize (i.e. the alternation appears to occur every other tick). This may manifest as vertical flow happening at both 3-tiles away and 5-tiles away. The distance increases with increasing initial mass, so the alternating simulation may simulate synchronized vertical flow with an offset of 2-tiles (or 2 ticks). I suspect that the maximum-distance-to-ceiling condition and the initial tick offsets determine how they synchronize.

I share this behavior so that we do not discount the alternating behavior as nondeterminism (i.e. not random).

On 1/17/2024 at 12:41 PM, Zarquan said:

I believe this shooting up is the root of this problem and might even be the whole problem, except that I can't seem to trigger it over 2 tiles.  I would love to see how its calculated and what triggers it.

Yes, I believe that you have identified the cause of liquid duplication in infinite storage as vertical tubes (and rectangular rooms). I have replicated the behavior in vertical tubes with height = {3, ..., 5} but not for height = 2.

P.S. You can step the sim with (Alt + -) since the vertical and horizontal flows are handled by the simulation.

Spoiler

In the five experiments in vertical tubes below, we start with a single liquid tile with an initial mass 3279000.126 kg (3279 kt + 126 g) placed at the bottom of the vertical tube. After the liquid in all tubes reach their ceiling, we measure the total mass in each tube (aggregated by the debug selection info). The total mass measured is displayed next to its corresponding tube identifier (A, B, ..., E). For brevity, we truncate the fractional part.

Results.

• Tube (A) does not duplicate liquid.
• Tubes (B, C, D, E) duplicate liquid (increases by +205 t from the initial mass) and generally increases with height.

Discussion.

These results agree with Zarquan's experiments where 3-tiles high is the minimal tube height that observe liquid duplication. Since the duplication increases with tube height, taller tubes duplicate mass with less initial mass (e.g. 2000 t will duplicate in a 10-tile high vertical tube). We have carefully chose the initial mass to be the minimal mass where we observe liquid duplication for the smallest vertical tube.

We also observe that the duplication does not occur until the instantaneous vertical flow occurs at fixed distance(s) from the ceiling. Recall that the vertical flow can trigger at two points with an offset of 2 ticks depending on how the system was synchronized with the alternating simulation in the previous spoiler.

I was not able to duplicate liquid in vertical tubes with height = 2.

Note that rectangular rooms also exhibit "turbulence" where the liquid tiles appear to exchange masses indefinitely. If we consider a rectangular room as a set of columns, then high-pressure columns will spill into lower-pressure columns by horizontal flow. If the lower-pressure columns satisfy the conditions for vertical flow, then liquid duplication may occur. This process may continue indefinitely unlike our vertical tube example.

Footnotes.

[1] For reference, the original periodic merging behavior by Kastrella. See the spoiler.

Spoiler

At 1x speed, over 48 ticks, liquids merge in the order L > T > B > R with 12 ticks in each merge phase. Gases merge in the reverse order.

The period depends on the machine and game speed. On my machine at 1x speed, the period is 4 ticks with 1 tick per phase.

[2] In my experience, high pressure liquids in rectangular rooms show "turbulence" as a combination of (a) vertical flow expanding upwards, (b) horizontal flow into adjacent columns, and (c) alternate vertical flow expansion in the adjacent column when pressurized. These systems may be in a sort of dynamic equilibrium by cycling pressurized columns.

[hydrotoast]

On 1/18/2024 at 10:58 AM, mathmanican said:

Here's a relevant link that may help. 

Thank you for this work. This is the closest model I have read to accurately predict "vertical flow" or "high pressure liquid expansion" as referenced in my first footnote. I have used this reference to determine that the "vertical flow" (or "liquid expansion") is not fixed (i.e. expands vertically into many cells per tick without clamping) on surfaces immune to pressure damage.

Of course, I do have commentary on two changes and some interesting consequences.

Change 1. A simple error. Configuration (E) has an error with the viscosity term.

• Original. m ≤ MM (9 + 12 C) / 5 - 2 V
• Change. m ≤ MM (9 + 12 C) / 5 + 2 V

After this change, you may observe that all configurations have a consistent (+ 2 V) term as you suggest in the post.

Change 2. Relax the surface constraint. I believe configuration (F) only appears if the surface is prone to pressure damage (as you suggest in relation to material hardness). If we use two or more layers of insulation tiles (or neutronium) as the foundation, then configuration (F) never appears with mass in the given bounds. Instead, the mass expands upwards (diagonally outwards) as expected. Hence can remove this configuration.

Consequence 1. Simplify the configurations. The configuration bounds listed sequentially after both changes:

• (A) m < MM + 2 V + .02
• (B) m ≤ 1.5 MM + 3 V
• (C) m < 2 MM + 2 V
• (D) m = 2 MM + 2 V
• (E) m ≤ MM (9 + 12 C) / 5 + 2 V

Consequence 2. A vertical tube corollary. As an interesting corollary, these bounds also determine the "expansion height" in vertical tubes after eliminating the horizontal flow terms (+ 2 V). For vertical tubes, the bounds listed sequentially:

• (A) m < MM + .02, the expansion height = 1
• (B) m ≤ 1.5 MM + V, the expansion height = 2
• (C) m < 2 MM, the expansion height = 3
• (D) m = 2 MM, the expansion height = 2
• (E) m ≤ MM (9 + 12 C) / 5, the expansion height = 3

Note the same the unusual behavior in the magic number configuration (D).

Finally, if we construct these systems on materials that are immune to pressure damage (e.g. neutronium or maybe doors), then expansion height appears to be nondecreasing with increasing initial mass. I believe that there is a possible closed form for the height (and perhaps a recursive mass assignment for each cell).

[blakemw]

Here's some more investigations.

There's also the phenomena I find strange, where if you paint a water cell with mass 201249, it erupts, with each layer being half as massive as the layer below. However if it is 201250 or larger it expands at 1 tile per tick for 3 ticks (with this normal expansion being roughly moving half their mass up), then erupts. I'm guessing the devs just hardcoded in a "200x" max for when "eruption" is allowed to happen (for water, 200x, 1000 for the max mass, 250 leaks to the sides), though clearly that isn't the only condition.

But anyway, the mass distribution in a liquid blob is super strange, like here's the blob that expanded from a single tile of 100,000 water in a single tick:

Googily sheet if you want text form and to play with calculations

Clearly there's some kind of "almost powers of two" thing going on up the middle column, in terms of the mass of the center column. Also excluding the first row, each row has roughly half as much mass.

However what I find especially strange is the severe asymmetry. Observe that in the second row (from the bottom) there's a strong rightward bias with the side lobe mass, with twice as much mass in the right side. In the 3rd row the mass distribution is biased leftwards, and it has spread two tiles leftwards. In the higher rows the bias is strongly leftwards.

Something else I find highly suspicious is that there are two cells with mass 771.5, two with mass 48.2 and two with mass 12.1. These spooky equal mass tiles on opposite sides in different rows are found in blobs of other masses too: lower pressure blobs are symmetrical, the equal values are on the same row, not different rows.

To wildly speculate, it could be that the shape starts as a normal blob, then gets deformed "from within", with cells getting pushed sideways or upwards to make room for further expansion. That'd be a very weird thing to do but ONI devs are known to do very weird things. It's certainly not normal/manifest "cellular automata" behavior and seems to be something deliberately coded.

[Zarquan]

I've been having trouble hammering down how this physics works in my head, but I have an idea.  Perhaps if we had a Liquid Physics Mod that allowed us to turn off the special conditional physics mechanics based on mass, that would help us figure out whats going on.  Like, the modder would find the conditionals (assuming they exist) and give us check boxes that allow us to enable and disable them at will, which would allow us to run experiments under a different set of rules.  Then, we could determine which rules are causing the problem if individual rules are the problem.  I believe we have shown that there is a major bug in how water expands and flows vertically, but since it does not cause duplication in a 2 tile tall room, it is either not the only culprit OR it is the main culprit, but it only happens when it works in concert with another mechanic.  It would be a lot easier to narrow down the cause if we could simply remove other variables. If we could turn off that mechanic, we could check to see if mass duplication is still happening.  Anyone know any modders who want to delve in to the weeds on this?

Also, I would love to see the frame in which a 2x2 mass duplication takes place.  I think I will try to capture it by finding a cycle in which it happens, and then (assuming the physics is deterministic) essentially binary searching time to detect the exact frame, but that sounds tedious, so any other ideas for this would be appreciated.  Should only take n*log(n) time with a massive coefficient for loading.  I can't think of a better way unless there is a mod that detects the sum mass in an area (another spontaneous mod request for debugging).

[Zarquan]

I have a save that consistently exhibits the mass increase within 10 seconds in-game time in a 2x2 area.  When the timer set to 600 green 30 red hits 121.4, the mass duplication takes place.

Here is the save, and a video below showing what happened.  I don't have time right now to try to piece together what happened.  I note that the left side lost a significant amount of mass and the top right tile gained a lot of mass, which is weird.

Ramshackle Rat's Nest.sav

 

[Gurgel]

I seem to remember this was essentially stemming from the short-floats (24 but mantiesse only, called "binary32" here: https://en.wikipedia.org/wiki/IEEE_754) being used, where, say, with 20'000'000kg, you only have a resolution of about 1kg. Rounding errors can then produce more mass. In theory, they can also produce less mass. Whether the increase is an accident, or intentional (people are more likely to complain on mass-loss than on mass-gain), I cannot say. 

This problem in unavoidable, unless you do what nature does, i.e. go fully integer and count individual atoms and use variable-size long numbers. That would completely kill performance though. On the other hand, impact is low. If you have a ton of material already, you get a little extra. If you have that ton of material, you most likely have a significant "legitimate" influx already. My take is this one only disturbs the purists and has no real impact otherwise.

 

[Zarquan]

1 hour ago, Gurgel said:

I seem to remember this was essentially stemming from the short-floats (24 but mantiesse only, called "binary32" here: https://en.wikipedia.org/wiki/IEEE_754) being used, where, say, with 20'000'000kg, you only have a resolution of about 1kg. Rounding errors can then produce more mass. In theory, they can also produce less mass. Whether the increase is an accident, or intentional (people are more likely to complain on mass-loss than on mass-gain), I cannot say. 

This problem in unavoidable, unless you do what nature does, i.e. go fully integer and count individual atoms and use variable-size long numbers. That would completely kill performance though. On the other hand, impact is low. If you have a ton of material already, you get a little extra. If you have that ton of material, you most likely have a significant "legitimate" influx already. My take is this one only disturbs the purists and has no real impact otherwise.

 

I am certain this is not a rounding error.  If I set the 2x2 tiles to 2,000,000 kg water per tile, it will stay almost exactly at 8,000,000 kg of liquid for several cycles until a specific event happens, at which point in increases in mass by a drastic amount (497.5 t) in one tick.  This repeats at regular intervals every few cycles.  That is not the behavior of a rounding error, which would instead appear as the mass either steadily increase or (more likely) decrease over time, that is the behavior of a buggy mechanic in the game.  It is far more likely that the mass is being calculated incorrectly in a way that could, and probably does, happen at lower masses, but in a way that is harder to pin down.

It is almost certainly related to rapid vertical liquid expansion interacting with another mechanic, possibly another instance of rapid vertical liquid expansion.  I suspect that the mass is being added multiple times.

[Gurgel]

Well, the rounding error is certainly in there, as it cannot be avoided. That does not rule out other issues.

Flowing of liquids and gases in Oni is not very well done. That is not a criticism at all, doing these "realistically" is exceptionally difficult, exceptionally high effort and still a research question today. So Oni does other things and these are error-prone. I find this mass increase does matter very little for the gameplay though. If you use infinite storage, chances are you are never going to empty it anyways, mass increase or not. 

That said, finding the problem would probably be pretty easy with a bit of instrumentation in the code itself. Just do a total mass check on a demonstration case in a fine-grained way. As you say, a 2x2 check area would already be enough. That should pin down the problem handily. But I think  Klei will not touch Oni base-mechanisms anymore unless they are really badly broken. This one is not really bad in terms of effects on game-play. 

[Zarquan]

15 hours ago, Gurgel said:

Well, the rounding error is certainly in there, as it cannot be avoided. That does not rule out other issues.

Flowing of liquids and gases in Oni is not very well done. That is not a criticism at all, doing these "realistically" is exceptionally difficult, exceptionally high effort and still a research question today. So Oni does other things and these are error-prone. I find this mass increase does matter very little for the gameplay though. If you use infinite storage, chances are you are never going to empty it anyways, mass increase or not. 

That said, finding the problem would probably be pretty easy with a bit of instrumentation in the code itself. Just do a total mass check on a demonstration case in a fine-grained way. As you say, a 2x2 check area would already be enough. That should pin down the problem handily. But I think  Klei will not touch Oni base-mechanisms anymore unless they are really badly broken. This one is not really bad in terms of effects on game-play. 

I would say the level of "bad" on this depends on at what level of mass it happens at.  This definitely impacts bases with infinite storage.  I set up a series of trials to run overnight and these are the results over the ~170 cycles:

1. <200,000 was unchanged
2. 300,000 kg/tile became 359,500 kg/tile
3. 400,000 kg/tile became 688,500 kg/tile
4. Oddly, 500,000 kg/tile did not change.
5. 600,000 became 3,893,600 kg/tile.
6. 700,000 became 743,500 kg/tile
7. 800,000 became 1,555,500 kg/tile
8. 900,000 became 3,393,200 kg/tile
9. 1,000,000 became 5,908,100 kg/tile
10. 2,000,000 became 6,648,800 kg/tile

These results are bizarre, but many of these amounts of liquid are readily achievable in an ONI game in a 2x2 space.  300,000 kg/tile takes 200 cycles at 10 kg/second.  600,000 takes twice that, and many colonies go significantly longer than that.  Also, many bases have significantly more than 10 kg/s input in to their infinite liquid storage.

I say that this breaks the water economy (or any other liquid economy) in bases that use infinite compression in this form, so it should be fixed or they should make infinite storage impossible.