Vanishing Steam Bug - Bug Report Requested


mathmanican
  • Branch: Live Branch Version: Linux Pending

As requested by @EricKlei, and @klei.ruby, here is a bug report related for the disappearing steam bug. At one point, I gathered a collection of resources related to this bug and put them in a "mass deletion" thread, which described several ways to loose steam in turbine setup.  The most relevant bug report related to this particular bug is @sheaker's bug report

Here are save files for autosaves on a colony at two consecutive cycles, so Tunnel Cycle 5.sav and Tunnel Cycle 6.sav. You'll find three steam turbines built to the left of the printing pod. Originally, all three turbines began with 300kg (20kg/tile) before starting.  After a few cycles, I added a manual automation switch to try and activate the bug. I haven't succeeded yet with that.  I added a timer on 10/10 default settings to the third turbine. After playing around for a few more cycles, the steam content dropped to 293.6 kg during the off phase. 

image.thumb.png.ed7be530db13be2d18a8aa72b74b8dba.png

I loaded my cycle 5 game 3 times today, seeing if the bug would activate on save/load.  The third time I loaded the game, I started loosing steam nonstop.  By the end of the cycle, the steam content in the lower chamber falls from 293.6kg to 162.4kg. That's over 130kg of steam lost in one cycle to this bug.  

I don't know exactly what caused the bug. I deactivated all mods once I purchased the DLC. I do have sandbox and debug enabled.  I cannot replicate the bug with every loading of the game. I did reload the game without exiting ONI completely (maybe it's related to that, who knows).  

What I do know is that I lost >130kg of steam in one cycle because of a single turbine.

 


Steps to Reproduce

I cannot guarantee you will be able to reproduce it.  Open cycle 5, let it run for a bit.  If the steam content doesn't start lowering, then reload the save. Try reloading the save several times until the bug starts occurring.

You can find people posting questions about this on the forums, on reddit, on discord, and on steam. The current "solution" is to add a liquid vent to the steam chamber, with a pressure sensor to refill the turbine when steam disappears.  When I ran this test above, the steam loss did not stop.  It kept on going throughout the entire cycle.

  • Like 1
  • Thanks 1
  • Wavey 1


User Feedback




....

Hi! So... I think I managed to make the bug buggier... In my save of @mathmanican 's original save "Tunnel2", it doesn't need reload and it happens on every load of the save file after opening the game and it loses more steam if run in 1x speed(at least for me...) Tunnel2_2.sav

My theory was to check if game speed could interfere in some way. I noticed when playing the game that abyssalite can boil crude oil to petroleum in 1x but instant boils to sour gas if playing in 3x. But I also think a specific point of time triggers the steam bug to have more steam loss.

The method to even reproduce it from the "Tunnel2" save is totally inconsistent. After filling every steam room without unpausing one save triggers the bug (Tunnel2_.sav) while another one doing the same thing (I think...) it doesn't (Tunnel2_fill-paused.sav)

I watched steam turbines run for several hours and it seems that there is a +- 0.4kg (0.05 and 0.35) of steam happening sometimes every cycle, sometimes every other cycle (have no idea why)

In the save "Tunnel2_2" and on another one(Tunnel2_3.sav) I upaused the game for 4-5 seconds in order to let all the pipes empty before filling the rooms with 20kg/tile steam

I also think that saving at a specific point triggers the bug and not only reload. The first time I saved the "Tunnel2_2" after filling the steam rooms the bug start happening before reload, just by saving.

  • Like 1

Share this comment


Link to comment
Share on other sites
....

I dug into the temperature aspect from my previous post a bit more and I found something I think is compelling.

First I adjusted the turbine output water temperature to see if that changed the critical temperatures that enabled the steam deletion.

image.thumb.png.e50a2efa1f4bf2aa8fc61f2d5a2dd2c3.png

From left to right, the output temps are 95C, 96, 97, 98, and 99. Sure enough the temperature of the steam where deletion would or would not occur changed as well.

From left to right, thermium (and steam roughly) are 376.9C (650K), 316.9, 251.9, 186.9, and 125.9. I didn't precisely find the min/max and there is wiggle room, but go too high or low and the deletion stops. Needing to heat the turbine water by 1C more requires roughly 65C more in steam temperature for deletion to occur.

 

Next I blocked one of the turbine ports to see what happened.

image.thumb.png.4c7365fc41835bbe6bf4a489edfa7da4.png

The necessary temperature deltas all dropped by roughly 1/5 (as you might expect with 1/5 less water flow). The 1.6 kg/s 95C water now only needed roughly 52C hotter steam than the 1.6 kg/s 96C water. And so on for the 97 and 98 water. I stopped looking at the 99 water because it's steam was already bumping into the turbine's minimum 125C to operate.

 

After some head scratching, I think I stumbled upon the important bit. The necessary temperature is at the vent and not where the water boils.

image.thumb.png.a663b6b5aa6df8644a5deea59ff549eb.png

The 2kg/s 95C turbine water needs very roughly 377C (again there is quite a bit of wiggle room) steam for deletion to occur. Changing the top or bottom thermium temperatures, and thus the boiling or turbine intake temperatures, does nothing. Changing the middle thermium however, and thus the steam temperature at the vent, stops and starts the deletion. Stopping happens almost instantly when the vent's steam temp changes too much. Restarting is a bit more difficult and took a couple attempts, but I did get it to happen multiple times.

 

If  the temperature of the vent cell is somehow important, I would suggest that perhaps the mass is as well. Is the sim using the vent cell mass instead of the boiling cell mass in some calculation or event? Or maybe cells next to the vent in the case of displacements? Is the deletion occurring at that cell for some reason?

 

Edited by wachunga
  • Like 1

Share this comment


Link to comment
Share on other sites
....

@wachunga, how reproducible are your temperature controlled builds?  Are they deleting mass on every load if you wait long enough?  Or are they randomly doing it on only some loads like others are seeing with @mathmanican's. And can you cause the bug to happen without messing with automation first?

Share this comment


Link to comment
Share on other sites
....

So it's definitely not the steam turbine's fault:

1133744067_Screenshotfrom2021-04-2612-22-05.thumb.png.cd491c507f8cb4cd23387f3a844e0fba.png

Starting from @wachunga's test2.sav (which is deleting mass consistantly every time for me, btw) I duplicated the temperatures and added 20kg/tile of steam to this contraption. 2kg/s of 95C water goes in and 2kg/s of steam goes out, but the total mass is dropping at an identical rate (afaict) to the steam turbines above.

My new theory: there is a race condition that let's the water in the vent interact with the surrounding steam before it is emitted.  If there's enough of a temperature delta to boil the water in 1 tick somehow it gets deleted. 

test5.sav

  • Like 1
  • Big Ups 1

Share this comment


Link to comment
Share on other sites
....

I think I replicated what causes the steam loss but I'm not sure... I was searching for the "when" the steam loss is happening but I think I found "why" the steam loss is happening. I just see it consistently.

I was able to make the bug of @mathmanican 's save to occur on every load. I didn't know how or why but making a random save made that possible (I would like someone to confirm if possible, that the save I've posted above makes the bug happen. Just open save, let it play at 1x, wait for the "colony lost" message and dismiss it and let the game play in 1x for a couple of seconds. Then letting it play either at 1x or 3x, I've seen the steam in all rooms having losses. Inconsistent and different loss at every room but occurring every time )

I created my own save in order to make the bug happen again and started observing steam turbines on and off and on again. I've noticed even when the mass of steam was remaining the same it fluctuated from time to time +0.4kg, -0.4kg or even more but found equilibrium in most cases. After that, I noticed the water packets the ST was outputting. They were packets of 2000g, 1600g, 400g, 1200g, 800g and I thought that when a particular combination was present the steam loss occurred.

Nope! So I opened again the save (Tunnel2_2) that the steam loss was happening to observe again. After ehmm... several more hours I see this:

So... what I think that I'm seeing is when the steam loss is happening, the vent is eating water packets..?

I still don't know if temperature is a factor as @wachunga is seeing but I was able to reproduce the vent eating packets without a steam turbine or automation (although I can't measure the loss accurately) but here is the save file Test_steam_vent whatever 6step.sav and that is what I've seen happening

What (I think..) I did, was save in an "offbeat" of the sim. First I've build everything and then using a timer sensor (in order to "see" between seconds) I used the "alt" + "=" command to step forward the game 5-6 times in between 0.1sec and 0.2 (sometimes there are 3 steps to change 0.1, sometimes there are 4) and saved the game. Quit the game and open game again. Load save. Unpause. After some times passes it fixes itself.

 

Edit: temperature is definitely a factor. After filling the room again with 40kg of 380C steam the vent is eating again

Edit2: or... maybe I have no idea what I am observing... (I can't reproduce the steps in a new save..)

Edited by sakura_sk
  • Like 1

Share this comment


Link to comment
Share on other sites
....

Evidence that water in the vent does in fact interact thermally with the surrounding steam:

1509655569_SteamTemperatureInteraction.thumb.gif.953759b64ab0f52984ee0bef80c97dc1.gif

Notice that the steam temperature drops slightly every time a packet of water comes.  There should be no interaction in the insulation insulated pipe or when the drop is emitted.

Edited by ghkbrew
  • Like 1

Share this comment


Link to comment
Share on other sites
....

@EricKlei or @klei.ruby, do we have enough examples in here for you to work on this?  As said above

1 hour ago, sakura_sk said:

I can't reproduce the steps in a new save

which means the bug seems to require something to trigger it initially, and then from there it can be propagated to other things. Both @wachunga and @ghkbrew appear to be using the same save I provided, and then modifying things. 

The fact that it doesn't require the turbine is a great find ( @ghkbrew), and I'll see if I can reproduce it on several new saves. :)  

The temperature issue is also interesting @wachunga, and would explain why the timer issue gets things in the right temp range.  Unfortunately, it doesn't explain why my manual switch on the original build didn't produce the bug. Perhaps the temp issue only matters once the bug hits. 

All the above seems to point to the physics/temperature simulation (maybe an interaction of the two).  And it suggests that something else is happening in addition to the pseudocode provided by @EricKlei. A race condition, a deletion condition, a timing condition, or something, seems like it's off.  Maybe someone accidentally touched a keyboard and added an extra 1 somewhere in the code before a commit went live.

How many of you have been able to reproduce the bug reliably on your own from a fresh save? I'm pretty sure I can get the bug to happen at this point on any save. 

Edited by mathmanican

Share this comment


Link to comment
Share on other sites
....
6 minutes ago, mathmanican said:

How many of you have been able to reproduce the bug reliably on your own from a fresh save?

I've reproduced it in a new save (not a constant deletion but some) and then made the second vent only video (my Test_steam map save), but then I couldn't reproduce the vent only bug in a new save from the get-go

  • Like 1

Share this comment


Link to comment
Share on other sites
....
7 minutes ago, mathmanican said:

@EricKlei or @klei.ruby, do we have enough examples in here for you to work on this?  As said above

We definitely have enough information, thanks everyone! Next step is finding time to allocate to investigating this bug, which might not happen right away.

  • Like 2
  • Thanks 4

Share this comment


Link to comment
Share on other sites
....

One last report, before I let the good devs at Klei take over.

2 hours ago, mathmanican said:

How many of you have been able to reproduce the bug reliably on your own from a fresh save? I'm pretty sure I can get the bug to happen at this point on any save. 

I've figured out how to reliably create new bugged saves. It seems the save has to occur in between simulation ticks, as @sakura_sk was suggesting.

Starting from a fresh world, paste this template: SteamDeletion.yaml

82064307_Screenshotfrom2021-04-2615-56-31.thumb.png.560a6e60b1d45e96a58173a26a819c33.png

  • Hook up the power wires (because templates don't save wire connections, but that's a different bug) and set the valve to 2kg/s.
  • Let the machine run for a bit on 3x speed and observe the lack of mass deletion.
  • Pause the game
  • Here you have two options for advancing a few frames (but less than a tick)
    • build some automation.  building 4 unconnected automation wires worked for me. (I suspect this was essentially what @mathmanican was doing to produce bugged saves)
    • manually advance animation frames.  e.g. press ctrl+= 3 or 4 times.
  • Without unpausing, save the file

When you re-load and unpause the game, it will begin deleting mass. You'll see that the total mass in the steam room steadily drops and that the vent's "venting animation"  only occurs every other water packet or so.

On new maps it seems to spontaneously fix itself after some time instead of continuing forever like on the neutronium filled map I was testing on.  I'm guessing other stuff on the map can knock it out of the "out of phase" behavior that causes the bug.

 

  • Thanks 2
  • GL Happy 2

Share this comment


Link to comment
Share on other sites
....
5 hours ago, ghkbrew said:

how reproducible are your temperature controlled builds?

I think we've moved beyond this question, but for completeness it's very reproducible for me just like for you. The few times it has failed might be because I accidentally broke it without knowing.

I built a similar contraption without the turbine like @ghkbrew and get the same results. To test if it's the packets or surrounding gas that's being deleted, I placed the vent in hydrogen. Hydrogen amount stayed the same while steam was deleted so I think that points pretty clearly to packets being lost. For a 2 kg/s water flow, the steam deletion was very close to 600 kg over one cycle. As if half the packets are being deleted. To double check this I changed the flow rate to 1 kg/s and adjusted steam temperatures as necessary. Sure enough deletion rate was then 0.5 kg/s or the same every other packet. I guess it could be half the packet amount instead?

I also tried the vent in oxygen instead of hydrogen but couldn't find the right temperature. The conductivity of steam and hydrogen are apparently close enough that the temperature for steam works for hydrogen as well. Oxygen is quite different. There might be some utility in finding the critical temperature for other gases, but I don't know if I'm going to bother. It could be an interesting way to avoid the bug though. Remove the vent from the steam chamber and stick some oxygen over it.

 

Good job everybody :)

Edited by wachunga
  • Thanks 2
  • GL Happy 1

Share this comment


Link to comment
Share on other sites
....

It randomly occurred to me that there is maybe a super simple work around to this. Rather than spending a bunch of dev time figuring out what causes the water flow to get into this unstable state, just insulate the vent. Not like insulated pipe, but like how the metal refinery and aquatuner and several other buildings are insulated. Their contents don't engage in temperature exchange with the surroundings.

storage.SetDefaultStoredItemModifiers(Storage.StandardInsulatedStorage)

My understanding is StandardInsulatedStorage Hides and Seals, if that causes issues then just Insulate?

Disclaimer: I am not a professional coder, yada yada yada.

 

And a screenshot showing the phantom contents of a vent exchanging heat:

image.thumb.png.94ead5c2594ca6e16bcc6b678c7d4571.png

The water enters at 95C and each tick adds ~1C. Maybe the critical steam temperature range is that which cause the 95C "water" to boil after 5 ticks at the same time a new packet of water enters the vent? If it's either 4 or 6 ticks the game deals with it ok? For reference, inside a building the water is treated as debris/bottle and boils at 99.4C and does not need the extra 3C "heat of vaporization" IIRC.

Edited by wachunga
  • Like 1

Share this comment


Link to comment
Share on other sites
....
1 hour ago, wachunga said:

Maybe the critical steam temperature range is that which cause the 95C "water" to boil after 5 ticks at the same time a new packet of water enters the vent? 

I apologize in advance for this not so misleading question? But I can't shake this scenario as I use it in some builds.

What happens with this setup if we superheat water so that it comes out as close to the steam chamber's temperature as possible? (As in using 1kg/s... It would mean splitting a turbine's output to 2 x 1kg/s lines)

 

On 4/26/2021 at 11:56 AM, mathmanican said:

Maybe someone accidentally touched a keyboard and added an extra 1 somewhere in the code before a commit went live.

In reference to another game: Maybe "coconut.jpg" was modified.

 

 

 

Edited by JRup
  • Like 1

Share this comment


Link to comment
Share on other sites
....
3 hours ago, JRup said:

What happens with this setup if we superheat water so that it comes out as close to the steam chamber's temperature as possible?

My guess is no deletion would occur and that's what I'm seeing so far in brief testing. I used the @ghkbrew method starting from scratch to achieve deletion with 1 kg/s 96.2C water into a 200C steam covered vent. No deletion when the water was superheated to 200C. Changing back to 96.2C water restarted the deletion.

I used this equation where x = water temperature in C, y = steam temperature in C, and z = flow rate in kg/s.

z * (99.4 - x) / (y - x) = 2 * (99.4 - 95) / (380 - 95)

Edited by wachunga
  • Like 2
  • Big Ups 1

Share this comment


Link to comment
Share on other sites
....
On 4/24/2021 at 9:26 PM, mathmanican said:

Agreed that this could be one possibility.  I've thought about it being a piping issue as well.  At some point, I'll run some tests with just pumps and no turbines, to see if I can get it to happen. 

@wachunga, I made a save for you to play with.  This one only has 10 turbines, as well as some fun experiments with bubble physics from @Qwertymenow's recent post (I wanted to radically increase the bubble creation rate, and noticed it was using similar principles as a bypass pump).  Here is a save that you should be able to open without the DLC. 

TestingGround Cycle 14.sav 155.5 kB · 7 downloads

You may have to load the game several times to view the bug in action.  I observed over 30kg of steam deletion from each chamber (average mass dropped from 19.9kg to 18.8kg) before I decided this save would work. 

To create this, here are the steps I followed:

  1. Create everything, fill pipes with liquid, leave aquatuners in off position. 
  2. Paint in 20kg/tile of steam to each turbine, and turn on aquatners. 
  3. After turbines are up and running, connect them to a manual automation switch.
  4. Flick automation switch off/on many times while game is running. 
  5. Delete manual switch, and replace with timer.  Let run for a bit. 
  6. Delete timer, and swap back to manual swith.  Flick it many times over 30 seconds or so. 
  7. Replace manual switch with timer. Let run, and then save game with timer in off state (not sure this part matters). 

From there, I just reload the save multiple times. 

I get the bug to appear quite often on a reload while game is open. I don't have to restart ONI at all.  Fun. This is the frustrating part, namely that reproducibility is tough. 

The fact that I have now been able, on 3 different maps, recreate the bug so that it occurs on multiple turbines all at once, tells me that it probably isn't the map (gonna put the tinfioil cap away for a bit @JRup).  

In the save I sent Wachunga, I connected all 10 turbines together before I started messing with automation toggles.  The 10 turbines seem to produce the bug at the same rate. 

Yep.  I agree. I'll check the other things you observed as well, to confirm them. Some are things I've noticed as well, but not really sure what they mean.  A piping issue with how the steam turbine puts liquid into the pipes could be it, however, I originally built all 10 turbines with a direct connection.  I only later swapped 5 of the turbines to use bridges.  Unfortunately, the bug started happening AFTER this change occurred (as it was then that I started fiddling around with constructing/deconstructing automation toggles). Next time I open the game, I'll deconstruct and reconstruct a pipe segment, and then save load the game, to see if that fixes the bug.  That is what I did in my liquid tank experiment (I save/loaded before running things). 

I think we have plenty here for @EricKlei and @klei.ruby to work with (I hope).  Lots of saves that are messed up, and hopefully a way to reliably produce more turbines that are messed up. 

First off, I agree that this is probably not a flow-based-deletion-problem.

Second, at this point I think what needs to be determined is the degree of independence vs dependence of component systems in the closed loop systems vs open loop systems. As well as testing for mutual exclusivity of certain events.

Third, for this we need to setup some controls. A lot of effort has been put into producing the examples where the bug does occur with some probability; we also need a couple of saves with variants where we think the bug might be reproduced but in which we can verify it absolute does not occur; the controls need to be very simplified like @wachunga's experiment.

So if we think the problem is pipes then we need to have a control which uses pipes in someway that we expect to reproduce the bug but which excludes as much of the other hypothetical causes as possible so like no automation, no oil, no aquatuners, etc; ideally each control has two and only two possible causes of the bug in it. Ideally, we have a model which involves as many of the hypothetical causation elements as possible but which 100% does not produce the bug after n loads or restarts or so on.

At this point, I would bank on there actually being a family of heisenbugs that are occurring inconsistently together rather than one all encompassing heisenbug with a single cause. It would be in our interest to setup a compendium of experimental setups that reproduce the symptoms of the bug but differ significantly in the implementation. Wachunga's reproduces the symptoms of the bug but does not use the aquatuner, oil, or apparent automation though derives from a setup which has been altered by a history of automation.

I would like to see an attempted example to reproduce the bug created from scratch which involves no automation at any point in the save anywhere for anything. If we think automation is causing this then we need to verify that we can not reproduce the bug without automation. Which means keeping steps 1, 2, and 7 of @mathmanican's protocol but ditching or replacing with non-automated alternatives steps 3 through 6.

I'd like to see an example of Wachunga's experiment which is open loop instead of closed loop like what mathmanican describes with the liquid storage outside the system; I am imagining an open water source that inputs into the system with the system being closed, and a variant where the system is relatively closed but the steam engines output the test sample into tanks at the completion of the experimental cycle, and a variant where water is piped in to the system and all water is piped out such that there is something like an infinite source and sink which allows us to watch the flow of mass through the system.

Finally, I keep reading mathmanican stating their save/loading protocols and their experience of failing to get it on first load after a fresh-start while getting it with some reliably after subsequent loads following failed attempts; we have cases reported by mathmacian that both indicate that the bug replicates on first load but not on subsequent loads and bug fails to replicate on first load but does on subsequent loads.

A number of people have also claimed to not get the bug unless they restart the game first as well as some people noting that they've observed this thing after long running games. Much of this points to some kind of improper/incomplete serialization of the game state or subsets of the game state especially with Wachunga's experimental setup and the 15 frame skip. It is important to establish control protocols for save/loading, restarting/non-restarting, and fresh-run tests vs long-run tests.

I have a suspicion that the state of some set of machines whether the automation or the steam turbines themselves is being improperly carried over from save state to load state which would indicate that something is not being properly re-initialized. I suspect that we could come up with a scheme to reproduce the bug in one distinct save then load a different map with a different setup and maybe get the bug reproduced reliably on subsequent save and vice versa for failing to reproduce the bug; I am not sure how far the cross save would contaminate the state of the machines.

As such, I'd like to see example setups which try to reproduce the bug without using the save/load trigger, without restarting the game, or where the experiment is only X many cycles or Y many seconds old. Cycles vs actual time spent on an experiment is potentially relevant as I have a suspicion this could be related to pause/unpause behaviors and how they interact with the state of the game and irreversible processes.

 

Overall, I am most keenly interested in the notion of the seeming randomness of the bug or bugs. There are aspects of the bug which seem very consistent but which might seem somewhat random because they depend on tiny variations in how the experimenters interact with and fiddle with the state of the game. Like how @sheaker hesitates multiple times in their video rapidly pausing and unpausing.

In standard scientific experiment with novel phenomena, you setup control experiments based on assuming randomness (no dependent relationship between phenomena) then testing to demonstrate that there is in fact randomness. Failure to demonstrate the randomness implies the existence of either a dependent relationship between phenomena or systems or a logically equivalent relationship; it demonstrates at the least correlation. If the correlation meets certain criteria and that criteria coincides with a couple of additional conditions in a satisfactory manner then we may be able to demonstrate that the phenomena are neither random nor merely correlated which implies probable causation; if there is correlation but not demonstrable causation then we may have demonstration of the mutual exclusivity of events.

In these cases, we are assuming various things about the dependence or independence of the simulation of (debris packets, solid cells, gas cells, liquid cells, temperature cells/packets, pipes, automation, functional machines, powergrids, and cycles/sim-steps), save/load serialization/deserialization of the simulation systems, OS/CPU/RAM interfaces with ONI, and the cycle vs system time vs real time relationships. Heisenbugs are a predictable result of cascading failures, byzantine faults, interdependent networks, very hard and very common concurrency problems like race conditions, and percolation simulations.

I suspect that the complex problems here are the result of some kind of race condition which can semi-reliably be reproduced by the save-load system. Basically, mathmanican has figured out good-enough-conditions for setting up the start of the race between the conditions, but how the race turns out depends on factors that are not well understood at this point in time and as Wachunga has demonstrated depends intimately upon the timing of those factors in relation to the state of the machines involved.

This, to me, indicates that at least some of the bugs involve systems that programmatically are assumed to be strictly sequential and classically functionally dependent but which are sometimes becoming independent or mutually exclusive resulting in chaotic parallel or concurrent processing conditions. It isn't quite random but it seems an awful lot like it is.

Which is the cause that I said in my original comment to Sheaker but which I attributed to the oil-water interaction; I now believe that it is more probable that the steam turbine itself may be undergoing some kind of race condition which results in a state that deletes water directly (still believe this has not be ruled out by experiments so far just that another bug is happening in the temperature and materials physics sim); Wachunga's experiment eliminates most of the cases that would lead me to conclude that something untowards is happening in the physics sim of the water-steam-liquids-gases interactions.

Edit: Pardon, I'm a bit of a slowpoke, and I just now read through page 2. Gist of the above post still applies though.

Edited by DaClown
logic
  • Like 1

Share this comment


Link to comment
Share on other sites
....

@DaClown Glad to see you back.  I have set exploring this bug off to the side, as the devs acknowledge the bug, they have actual code they can use to track it down, and so I'll trust them to fix it (or forever leave it as ONI lore).  

Share this comment


Link to comment
Share on other sites
....

I was screwing around with alternate ways of boiling liquids and I thought I would apply it to this issue to see what happened. Maybe it'll provide some insight.

First some background on how I understand things to work so we're on the same page. Contents of buildings behave as debris/ore that are invisible. This includes liquids, bottles are the graphic for liquid in debris form. Debris melts/boils at the material's melting/boiling point and doesn't require the extra 3K that is needed when the solid/liquid comprises a cell. Debris also does not have the 1.5K rebound after phase change. Some buildings are flagged as "sealed" which, AFAICT, prevents the contents from offgassing or changing phase. An interesting quirk occurs with buildings that are not sealed.  Liquids that are "transheated", I'll define as above boiling point but below the extra 3K (water @ 374K for example), are stable as a cell or in pipes but will spontaneously boil when placed in an unsealed building. Doing so avoids the 1.5K rebound, which is what I was initially after.

image.thumb.png.84b6cb64daf807e2cdfc171560cc6a88.png

Soda fountains are unsealed and the water inside boils when it reaches 372.5K. I wanted to see if boiling water this way triggered the deletion, if so then behavior specific to the vent could be ruled out. Using the equation from a few posts up, I got deletion to occur without a vent. In this configuration of 1000g/s water flow, the deletion is 500g/s or half the flow rate which is what we've seen previously. However, connecting one of the side branches reduces deletion to 250g/s which suggests spreading out the packets from every other to every fourth stops the deletion. Connecting both side branches stops all deletion. I briefly tried adjusting temperatures to restart the deletion with 4 branches but was unable to. Returning to 2 branches restarted the 500g/s deletion. Perhaps alternating flow between multiple vents is an easy way to avoid the bug?

And the save for any interested:test.sav

 

Edited by wachunga
  • Like 1

Share this comment


Link to comment
Share on other sites



Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now