• Content count

  • Joined

  • Last visited

Community Reputation

95 Excellent

About Hexicube

  • Rank


Don't Starve Together
  • Contributor
Oxygen Not Included
  • Alpha Contributor

Recent Profile Visitors

501 profile views
  1. Testing apparatus: Abyssalite is spawned in at 1K, 100kg tiles. One 1kg tile of oxygen is added at 100K in the top-left tile. Observe how as a gas the oxygen is losing about 0.1C per in-game second, but once it liquidates, thermal transfer is drastically reduced despite the large increase in conductivity (0.024 to 2.0). Additionally, one can observe casually when digging in the oil biome that oil dropping onto 1500C abyssalite will instantly convert the oil into petroleum and then sour gas. However, once the abyssalite drops below those phase change temperatures, the reaction instantly stops. There is a clear disconnect between mechanics, either abyssalite should be conducting with liquids better (to match gasses), or gasses are over-conducting and the phase-changing is a bug (to match liquids).
  2. Selecting the grill causes a very visible FPS drop, even if the game is paused. The attached save shows this issue. Move around with WASD without unpausing, then select the grill and move more. Q1 Test Save.sav
  3. This should be DTUs to match everything else. In this case, 93.6MDTU (93,566,480 DTU).
  4. You can get more from rockets. It's expensive, but a wort lasts forever.
  5. No, but that's a huge discrepancy. It's closer to the low end than the high end and is dying due to too high a temperature.
  6. They have a massive liveable range, with the top end being 100C. Dying from heat 60C below their stated max temperature looks like a bug.
  7. As shown, FP germs are dying at a temperature that used to be very normal for them. Additionally, FP germs are dying in polluted water. The menu claims that germs are growing, but the number is decreasing.
  8. Whoops, yeah, 1671kDTU/s. That's actually pretty high.
  9. The sieve is one of only three buildings that I'm aware of that have a fixed temperature output, the others being the electrolyzer (70C) and the steam turbine (226.15C). It's clearly intended. Now, if you want to talk balance and not bugs, this should stay in place until the AETN gets a buff first. It's garbage right now at -80kDTU/s. For comparison an always-on metal refinery processing gold (lowest heat recipe) produces 16kDTU/s from being a refinery and ~264kDTU/s for processing gold. Steel makes it produce ~2339kDTU/s, something only a steam turbine can reliably control with its minimum 3100kDTU/s heat removal. By comparison, the sieve is a joke, removing at most ~167kDTU/s (120C pwater to 40C water at 500g/s). Barely exceeds two AETNs.
  10. Still present on 296878 for existing saves, see attached. Q1 Test Save.sav
  11. Dupes Exp Gain Bugged

    I misremembered, then.
  12. Dupes Exp Gain Bugged

    Jobs are unaffected, they use the interests system where dupes will be twice as fast for jobs that they like. Leaning is specifically for attributes, and research speed.
  13. Doors maintain a fixed temperature, whatever they are built at. Any heat changes are applied to their underlying tile, but are not reflected on the door itself, and a save-load resets the underlying tiles to the door temperature. Opening and closing the door updates the door's temperature. Opening the door and closing it before it fully opens appears to set the tile temperature to the old door temperature.
  14. This is a stable fluid configuration. Even though crude oil has a higher molar mass (is "denser"), it will not form a layer below the water. Chances are there's no check to see if the tile above is denser than the tile to either side, in order to prevent this strange formation from happening.
  15. This seems to be a long-standing issue and is one deeply rooted in the game's update logic. As it currently stands, ONI tries to do 5 update ticks per second, with the rate of these ticks varying based on the chosen simulation speed. The problem lies in the fact it tries to cram this entire update into a single render sub-tick (locked at 60fps, 12 sub-ticks per tick), causing visible stutter if an update takes considerably longer than one sub-tick (even though actual ticks are 12 sub-ticks apart). This leaves 11 sub-ticks where no actual logic is performed (except for smoothing out the changes). Poking around in decompiled code, I've noticed the functions "SimEveryTick(dt)" and "StepTheSim(dt)", with the latter having a bunch of sub-simulations within it (and also likely being where the CPU hit is). My thought on this is that these sub-simulations could be spread across sub-ticks, making better use of available CPU time that is otherwise not used at all, instead of trying to do it all at once. The issue is particularly apparent on slower sim speeds, as the time spent not doing anything will be larger. You can also tell this is happening by the fact the stutter persists on slower sim speeds despite lower CPU usage.