Lunkdolt

  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

6 Neutral

About Lunkdolt

  • Rank
    Junior Member
...

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Enable
  1. One way to get a similar bug to reproduce is to build a mechanical airlock, then build something that requires resources to be delivered to it, like a Deodorizer right behind the door. The dupe will start opening the door, the start building the building, the animation will break, but dupe will remain on the near side of the door (the building behind on the other side), the loading bar will then disappear, but after a while, the building will have finished. The same will happen when the dupe is going to take sand to the deodorizer. I just built a new manual air lock to confirm , and a dupe was trying to pick up something right in the first tile behind the manual airlock. he got stuck before the door, just stood there, but magically picked up the sand regardless.
  2. Atomic Collider, Germs tab (same amount of germs as the Radbolts inside the Atomic Collider "contents") The Germs tab has Surrounded by: 100% dead/cycle, however, the tooltip (for Surrounded by) is saying "...causing germs to multiply". The germs are indeed dying off, not spawning. The Dying on: 50%/cycle tooltip is correct:
  3. It's true, the radar works fine for most applications (at least for my applications) through the bunker doors as well. I believe it's so that the more scan quality you have, the longer the warning time before meteor shower (or incoming rocket). 0% scan quality is essentially 0 seconds of prewarning. I cannot comment on the superspeed, because i have never used anything like that. Is it normal or debug option?
  4. Has happened to me with 2 dupes too. Saving/loading helped.
  5. There is no "bug" that i can see. Your scan quality is lacking. The radar clearly detects something, that forces the doors to close. When the doors close, your scan quality will drop to zero, which means the radar cannot detect the incoming meteor (or other object) and thus it will give an "all clear" signal, causing the doors to open. This will then begin to repeat. A solution would be to use a Memory Toggle: In this case, the radar will detect a meteor shower, thus closing the bunker doors. The doors will remain closed, until you give a positive input on the Reset input of the Memory toggle (like say, a switch). This is not fully automatic, as you would still have to manually control the reset switch, but it's better than having the bunker doors automatically open.
  6. Looks ok? The input pipe runs from the first pipe to the 4th , then there is a small gap (i didn't change anything), then there are the four other ones. I can't seem to reproduce this issue. I have plenty of bristle berries hooked up in a similar fashion: No issues so far. The game was "created" in qol2 in test branch, now since upgraded to "live". Maybe that has something to do with it?
  7. When duplicants are assigned to Pharma Chambers and are actively inside them during save (such as during the cycle autosave), everything is fine. When said savegame is loaded, Duplicants that were sleeping inside the Pharma Chamber, fall out right outside the Pharma Chamber with the Incapacitated modifier (even though they walked to the Pharma Chamber on their own). Fringe.12 Cycle 479.sav
  8. This is hardly a bug and it makes sense. Typical similar sensors in IRL building automation require external power. It makes sense that for example temperature and pressure sensors do not need external power. Same goes for most of the the liquid-in-pipe and so forth detectors. If anything is a bug, it is that some sensors that should in reality require external power, in fact, do not. At least according to ONI physics. I feel that it's intended to require power and adds variety to the game