• Content count

  • Joined

  • Last visited

Community Reputation

186 Excellent

About wachunga

  • Rank
  1. The 1/100 is incorrect. While it is indeed in the code, it is not relevant for heat transfers. A dirty little secret is that the dev team isn't particularly competent and there is all sorts of vestigial/deadend code. You can easily confirm this for yourself. The wiki page even has an example that demonstrates this.
  2. The wiki page on this stuff is pretty good now and includes the changes since that original post. https://oxygennotincluded.gamepedia.com/Thermal_Conductivity Those editing the page are heroes the community needs but doesn't deserve. Note that there are some minor details missing, but they aren't very important in the grand scheme of things.
  3. I think it would fun if each room type had it's own pool of paintings. Bedroom could be the stereotypical cat playing with a ball of yarn, or pip playing with a seed for the ONI universe. Washrooms could be something along the lines of "All Dupes Must Wash Hands". Great Hall would be a menu. Hospitals promote dupes getting their flu shots pills. Power plants with OSHA type safety warnings. Nature Reserves have "No Littering" or "Save the Asteroid" messages. And so on.
  4. From my testing there is nothing special about tempshift plates. They are simply a 3x3 building that can be built virtually anywhere without interfering with anything else. Under a tile being the exception. For the actual calculations, "q = conductivity1 * conductivity2 * dT * (mass*SHC of the hotter thing /5 if a building) / 10 per tick" is still accurate last I checked. Buildings that span multiple cells are a bit more involved but still follow that principle. In a building that spans n cells, the heat transfer from any single cell is hard capped at dT/n. So for a tempshift plate interacting with one cell with a difference of 90C, 10C per tick is the most the plate can change by. The change of the cell is calculated off the heat transfer necessary to achieve the plate's temperature change. If the plate is interacting with two cells each with a 90C difference, it then becomes a 20C change at most per tick. Note that there is a soft cap in addition to this hard cap. At 60% of dT/n the heat transfer (as governed by the above q=k1*k2...) starts to become reduced. I've never bothered to figure out what this reduction is. The math nerds can gather a bunch of data, plot a graph, and figure out the relationship if they really want to. Presumably the game sums up all the individual cell interactions to give a final temperature for the tempshift plate (or any other multi-cell building). I'm no longer inclined to put in the time gathering data, but anyone curious about this stuff can easily test it for themselves in debug. Use Alt- to advance one tick and the sample tool to read temps.
  5. It's a bug. Coincidentally it's come up in another thread so I'll quote myself. And for good measure, my bug report:
  6. Yes, I edited my post after you read it to explain that issue. It's another bug where debris sitting on insulated tiles behave as if the tile is un-insulated. So the debris is forming a heat pathway that ignores the insulated property of the tile. The oil in the steam chamber heats the debris which heats the insulated tile which boils the water.
  7. I'm guessing this is a result of what I call the "sweating" mechanic. Other people probably have different names for it. This occurs when a solid/liquid is in contact with a tile that is higher temperature than the melting/boiling point of the solid/liquid. What happens is that a small portion (the 5 kg) of the solid/liquid instantly melts/boils. Presumably this is to model a huge chunk of ice (or anything else) melting gradually rather than all at once. The problem is that this mechanic ignores conductivity. Most commonly seen in the oil biome when super hot abyssalite (from the magma biome) cooks oil into petroleum or sour gas. With abyssalite's very low conductivity this should never happen, but it does. It's a bug or very stupid design decision that has been around forever. So what I think's happening is that 5 kg of polluted water is being semi-randomly boiled into steam because it's in contact with the insulated tiles between the water and the steam chambers. Check the temperature of that one tile above the clean water with the debris on it, I would venture it's above 120C. A result of another longstanding bug, insulated tiles don't act insulated with regard to debris on them. The steam is then cooled by the cold polluted water and condenses into the 5 kg of water you are seeing. For a solution, swap the polluted water with solid metal tiles. Or use crude oil instead of polluted water. Or separate the polluted water chamber from the steam chamber such that the polluted water no longer touches a hot wall. Please do report back if I'm correct on the problem.
  8. Just did a brief "calorimeter" test and can confirm that splitting debris/stacks generates effectively infinite heating or cooling. Limited only by how many times you split. Start with 100kg of hot diamond, put 99kg of that somewhere else. You now have 199kg of hot diamond heat energy. Pull 98kg out of the second pile and put somewhere else. You now have 297kg of hot diamond heat energy. Repeat ad nauseam. The challenge now is engineering a system to do so. The usual suspects should have a blast with this.
  9. I think this is a bug with debris in general. A debris pile doesn't seem to update it's thermal mass after part of the pile has been removed. I've noticed this with ice debris. Typically I'll make a simple ice melter setup by having a bunch of compactors for small amounts of ice in a tank of water. Periodically I'll gather a bunch of ice into a large debris pile that gets swept into the compactors. The small amounts in the compactors melt quickly and dupes refill the compactors. The main debris pile melts as if it had it's original mass even when it's down to almost nothing. A picture may explain better. Started with 200 kg of ice debris. 50 kg went to the center compactor, 100 kg to the right compactor, and 50 kg left on the floor. After a few moments, the difference in temp of the 100 kg compactor ice was half that of the 50 kg compactor ice, as expected. However, the difference in temp of the 50 kg floor ice was one fourth that of the 50 kg compactor ice, as if the floor ice was still 200 kg. I haven't bothered testing other types of debris piles but there is potentially a huge exploit here. Given the other debris bugs, debris is very poorly implemented and super janky.
  10. The bump thing only happens with a solid tile. Look at the debris at the bridge output, ignore the debris in the box. With no solid tile, the debris is located at the output. With a solid tile at the output, the debris jumps up to the cell above. With a solid tile at both the output and cell above the output, the debris is now captured in a solid tile for maximum heat transfer. It's not just a visual artifact, there is indeed a difference in heat transfer between #2 and #3.
  11. Yes I need to learn to forum and tag.
  12. I decided to go with the throw **** on the wall and see if anything sticks method and did a General Discussion thread instead! But if Bug Tracker threads are what get you going, how about: Save file in my report. Apologies to any threads I might have missed. Your sacrifice has mostly likely been in vain.
  13. As some of you may know there is a bug where material on a conveyor that is offscreen may not transfer heat with the cell that it is in. More specifically, when the conveyor is offscreen to the northeast or southwest quadrants the bug occurs. When offscreen to the northwest or southeast quadrants heat transfer appears to be correct. The bug seems to be that material on the rail acts as if it's in the cell that originated the length of rail. That is to say the cell with the output of the loader, shutoff, or bridge from whence the material came. As a workaround, ensure that the output of your loader/shutoff/bridge is in a cell with which you want to exchange heat. For a typical example of running hot igneous through diamond blocks, you must use a bridge that has it's output in the diamond. A loader in vacuum transfers no heat because the game thinks the material is in vacuum regardless of where the rails actually are. Note that this doesn't avoid the bug, it just minimizes the problem. All the material on the rail transfers heat with the first and only first cell. You must rely on cell to cell to transfer heat further. You'll notice there is a bump above that first cell. This is because when material comes out of the bridge into a solid cell, it jumps above the cell and transfers heat as debris ON a cell, which is slower than debris IN a cell. That bump enables faster heat transfer and again all the transfer is concentrated there. For your typical loop with an automated shutoff, ensure both the input bridge and loop bridge have their outputs in a heat exchanger cell. Something like this, stolen from Lifegrow : The more "creative" of you may already be thinking of dirty tricks to exploit this behavior. Anything that melts on a bugged conveyor melts as if it's in that magic first cell. Each 20 kg conveyor packet behaves as a separate debris pile for heat transfer, so 100 segments of rail = 100 piles of debris. The heat transfer of 100 piles of 20 kg is much, much, MUCH faster than 1 pile of 2000 kg. Do your worst and maybe Klei will pull their finger out long enough to fix this very old bug. With thanks to Lifegrow for being my muse while I investigated the issue. And as always please share any further discoveries.
  14. Run tests, gather data, fit an equation to that data. Run more tests, try to disprove that equation. Share your results. Alt- in debug advances the game one tick. The sample tool in debug gives you a cell temperature to 4 decimal places. Gathering data is trivially easy. Cell to Cell (Tile to Tile was a potentially confusing choice of words on my part) has recently changed to geometric mean instead of lowest conductivity. I have always advocated, and asked, for people to run their own tests. The community has refused to do so. They would rather endlessly speculate and regurgitate misinformation. If a tiny fraction of that time was spent doing their own tests, these questions would have been answered a hundred times over.
  15. I did some more testing. Please excuse the extra post. It now appears that the conductivity controlling cell to cell heat transfers is the geometric mean. Square root of the two conductivities multiplied together. CellToCellHTTest.sav Initial setup is 2 blocks of 100 kg of 0C granite. One touching 100 kg of 50C wolframite and the other touching 100 kg of 50C tungsten. Use alt- to advance the game one tick. Then use the sample tool to determine exact temperature change. The wolframite changed by 5.3216C and the tungsten by 10.6432C. This is 71,309 J and 142,618 J of heat respectively. 5.3216 * 0.134 * 100,000 = 71,309 and 10.6432 * 0.134 * 100,000 = 142,618. Plug in the various values for q = sqrt(k1 * k2) * dT * 200: Sqrt(3.39 * 15) * 50 * 200 = 71,309. Sqrt(3.39 * 60) * 50 * 200 = 142,618. Again, the big question is "Klei, what is the intended behavior?". Please share any tests to the contrary, but be aware of clamping that causes odd results in cell-cell transfers. Note: I forgot to disable mods on the save, but behavior is the same without the mods.