Zippy95

  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

4 Neutral

About Zippy95

  • Rank
    Junior Member
...
  1. I have seen the -272.2°C structures (and they don't absorb nearby energy until the save is reloaded) but I haven't seen the super-heated ones... until now. The cold stuff is within a manageable range of temperature – a 100kg ladder or five won't break your base in all likelihood – but the hot stuff is ridiculous. The highest temp I have seen reported in the bug tracker so far is ~400+ nonillion. So fast forward a bit: I haven't seen the issue pop up in my save so I keep playing. One of the issues I have had is gasses supercooling in random lengths of pipe, but the hotfix build has fixed that. In the (hopefully attached) save, I have this pipe that I have been venting deeper undesirable gasses to space with, and none of the pipes were built at abnormal temperatures. I looked at them again a bit later, and I saw a few pipes had turned red, and next to them, a few had turned blue.... The hottest pipe is 20.1 decillion °C (if I counted the zeros right). Now they won't explode until I reload the save (and it does explode when I do that, bypassing the black hole and crashing straight to desktop), so I have hope that if I take sandbox delete to them, the save will be recoverable. I tried this and saved that separately, but haven't tried reloading the 'clean' one yet. Linux version, cosmic_upgrade_hotfix enabled. Ohno.sav
  2. Are you sure that's what it is releasing? The hot steam vent (from the vents I have seen in my own games, not actual data, though this may count) produce much smaller masses of steam per second. Given the relatively small amount of mass the steam has compared to the solids surrounding the vents in those images, the steam would cool off fairly quickly, with the hot steam vent actually cooling off faster and more thoroughly because of the smaller quantity of steam. If you were to surround them in vacuum and insulated abyssalite tiles, I would expect the hot steam would be much hotter, but with much less mass. Neither of them actually release liquid water. If any of this is not the case, there could be an issue, but I can't exactly verify anything with only those two images.
  3. Do note that I have tweaked the worldgen files (copies of them, really) to make the map size 512x512 and to increase the geyser count similarly for this map, but that is all. I would have tested this on a standard world if I knew of a way to set up a ranch and tame a puft without playing through that far. Supernova IV.sav
  4. This holds true with both airlocks and the pneumatic door, and affects a number of creatures. I have tested this by spawning them in with sandbox—notably, they take a few seconds to unfreeze and obey gravity when spawned in this way—and having a duplicant open the door, which comprises the only 2 blocks they could stand on. All creatures continue to pace back and forth without falling pretty much ever, suggesting that so far as they are concerned, it's still a completely valid floor. Additionally: A flopping Pacu will not obey gravity immediately upon jumping over a hole, and debug teleporting one out of water will take a few moments—even while the game is paused—to realize that it should be flopping. Teleporting one back into water may take a moment too, and the Pacu doesn't seem to be able to figure out it's in water while the game is paused. I don't know if this is related or not. The Drecko considers the doors to be open and solid at the same time, as it can crawl onto the inner sides of each tile the door covers. (I don't know how to describe it—just see the screenshot.) The Slickster actually falls through the opened door pretty quickly. So far, this is the only one that I have tested that does so. When I destroy the door, the creatures keep floating for some time, but they stop pacing. They float for about as long as it takes the Pacu to finally fall down a hole while flopping. (Some images have the game paused, but in all cases, the critters were floating before I did that out of habit.) The slickster is just starting to fall in the screenshot below: The Drecko, however, has no such plans: It took more than 10 seconds for them to fall down after deconstructing the door, but probably less than 30. (I didn't exactly count.) This is about the same amount of time that it takes one of my Pacus to vertically navigate with the power of gravity:
  5. My pufts are generally happy (even after they enter the "starving" cycle). As shown below, when they hit 100% reproduction, they will not lay their egg. The pufts stay at 100% for as long as I play, only laying them upon reloading the save, necessitating that I reload the save for every egg (or more at once, if I had more pufts) that I want them to succeed in laying. Other creatures and wild pufts are laying eggs normally.
  6. My duplicants are irregularly ignoring optimal storage compactors in favor of filling up nearly-full compactors, sometimes quite far away, regardless of their distance and priority. Burt was kind enough to give us an example: We're cleaning up (sweep command, priority 6) a large area just off the left side of the screen, and there's plenty of storage nearby, some of which has a priority of 6 (+1 over every other storage with the sole exception of the wort-seed-only storage, which is not involved). In the image below, we see Burt ignoring all of it one cycle later in favor of this nearly full one a little farther away. Maybe he just wants everything topped off? Nope. Just a little bit earlier, he's gone to deliver an extremely small packet of sand to the same storage compactor, and it's not enough to top it off. This is a duplicant that can carry up to 1640kg, and I have seen that they will gather multiple debris together and use multiple storage compactors for a more optimal delivery run before. I have seen all of my duplicants doing this, going more than twice as far in some cases. After the above example, Burt proceeded to fill up other, nearly-full-but-not-very-close compactors. I can't figure out why. In one case, I de-prioritized one apparently-highly-preferred compactor (down to 1), and the duplicants proceeded to fill up the local, high-priority compactors for a time. I am as of yet unsure if reloading the game has any effect on this, but it doesn't seem to.... except that I have previously had difficulties (only observed twice) getting my duplicants to use freshly-built (i.e. the save has not been reloaded since their construction) compactors—and a fish feeder in one case—and those compactors were 100% ignored until I reloaded. I don't know if that was in favor of the nearly-full compactors, as I had not yet clearly observed that preference at that time.
  7. I had a fish feeder that my courier (as per the priorities I set) wouldn't touch at priority 9 as well. Nor would any other duplicant. In my case, this was resolved by reloading the save. I have recently noticed quirky behavior about where the dupes want to deliver things, and wonder if this is related at all (provided that I figure out what they are doing and haven't overlooked anything – still testing).
  8. Taming a puft appears to increase its kcal needs from ~50kcal/cycle (if I understand the wild puft tooltips correctly) to 200kcal/cycle. The "Glum" state reduces this by 80%, down to 40kcal/cycle. I'm not sure how many kcal this little guy is taking in, but he's in a cycle of starvation and having about 20kcal in the tank. Being tame and happy (normally), this disappears quickly and the puft starts "starving". With 10 cycles left to live if he doesn't eat... he takes in more polluted oxygen a few seconds later, clearing the starvation timer and becoming happy again for another fraction of a minute. The puft next to it is slowly dropping from 1000kcal. It's at about 300 after several (I haven't counted) cycles. I ruled out oxygen density, I think. At first it was ~800g/m3 (and why is gas pressure measured in terms of mass anyway?), so I pumped in enough to put it as high as 6.9kg/m3. The puft still "starves".
  9. I have observed this too. It appears that the room they are in keeps track of critter counts for them, as making their pond a part of a room immediately limits their reproduction. If their pond is not a part of a room... I've been keeping their numbers down manually, but they have no sense of overpopulation.