• Content Count

  • Joined

  • Last visited

Community Reputation

286 Excellent

About kbn

  • Rank

Recent Profile Visitors

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

  1. I don't think there's anything wrong. The bacteria count in the tank indicates that there are 524 bacteria in 5000kg of water. The pipe on the output side draws 10kg of water from it. Therefore, the number of bacteria in the pipe is diluted to 1/500. 10kg/5000kg * 524germs = 1.048germs
  2. Yes, you are correct. But that is just a standard definition, and I think it is up to individual implementations to actually decide what that undefined behavior will be. And in fact, the memory toggle implemented in ONI is designed to explicitly output 0 when both inputs are set to 1. So I thought it would be better if the output when both inputs are changed to 0 at the same time is also unified without becoming unstable. In that sense, this may have been a suggestion rather than a bug report.
  3. aaa.mp4 I think it has something to do with the length of the wires or the order of the connections, but unfortunately I couldn't quite figure out the definite rule of thumb. In any case, I think it's not good to have inconsistent behavior like this, so I think it's better to unify them. By the way, it may be the same story as this bug that appeared when searching past cases. However, I didn't know if this was really the same thing in the story about two years ago, so I posted it as a new bug.
  4. If you send a red signal at the moment the Mechanized Airlock finishes its opening action, it will be open but jammed inside. I think this is a bug that can occur in any system that uses a sensor signal as a trigger to control the opening and closing of a Mechanized Airlock. For example, in my NG gas generation system, this bug often interferes with the flow of sour gas. I'm checking this in the DLC environment, so I haven't confirmed if this occurs in the base game. However, I remember seeing similar Mechanized Airlock clogging a few times in the past, so it may be a bug from the base game. I have prepared a save data for the reproduction test. We will do a brute force test in 0.1 second increments, so we can confirm that the bug occurs in a Mechanized Airlock somewhere. Where it happens may probably depend on your hardware environment.
  5. Good pick up. The fact that 15.10kg > 15.9kg is very strange.
  6. It disappears when the lower body of Dup passes there. It doesn't seem to disappear when passing by climbing a wall.
  7. As far as I read the update, it's probably just a modification of the template used to generate the world. In other words, the fix for the unknown area of the problem will not be applied to the existing stored data, but will be reflected from the new world.
  8. There is a solution in the comments here. However, I think it is a bug that this unknown area is generated.
  9. The notation is difficult to understand, but I think it is a value based on 0 Kelvin (-273.15°C). -273.2°C +348.2°C +200°C = 275°C
  10. Besides melting with heat, there are other ways to mine natural tiles protected in this unknown area. By building a part of the building so that it hits an unknown area, it can be forcibly mined as part of the construction work. Alternatively, if you can make a Robo-Miner, you can use it for mining.
  11. I don't think this has been fixed. I didn't participate in the alpha test and just bought the DLC today, so I don't know the past details, but when I tried it, the MUD melted by heat from the adjacent tile changed to COMPOSITION. However, the MUD melted by the heat from the Tempshift plate changed to VOID. In the case of the Tempshift plate, if you look closely, you can see that it seems to change to COMPOSITION for a moment and then to VOID. BUILD:EX1-444349-D
  12. I'm sorry, the description I wrote above may be verbose and confusing. (And since I use google translate, I'm worried whether the intention is conveyed correctly) As another reference, I will upload a video that visualizes the signal fluctuations in advanced mode and normal mode with a pixel pack. I will also upload the save data. The signal counter in normal mode is on the right, and the signal counter in advanced mode is on the left. You can see that every time the duplicant disassembles the wire, the advanced mode signal is noisy, but the normal mode signal is not at all. The problem I want to convey is, in short, this noise part. It's probably enough if you understand that.
  13. Building or demolishing buildings or wires with automation capabilities will update your automation time by one tick. We recognize that this is a game mechanics that many people who have played with automation in the sandbox are aware of. So this is fine in itself, but there is a problem that the advanced mode of the signal counter does not properly support this mechanism. The signal counter on the right is in normal mode and the signal counter on the left is in advanced mode. As you can see, the signal counter in advanced mode cannot properly respond to automation updates during construction / demolition, and outputs a signal of 1 tick or more. This was paused for clarity, but of course the same thing happens with normal real-time duplicant construction / demolition. An obvious problem is when combined with an XOR toggle circuit that relies on a 1-tick signal. In this way, the state of the XOR toggle was orderly at first, but due to the overlapping timing of construction / demolition by the duplicant, a 2-tick signal was transmitted, and the state of the XOR toggle went wrong. This means that automation systems with precise tick control can have problems. Of course, to avoid this, you can do it by adding a logic gate to make the signal 1 tick, or by not using the advanced mode in the first place, but that makes the circuit a little redundant. The advanced mode of the signal counter is an easy-to-use feature. So if this is an unintended bug, I hope it will be fixed someday.
  14. There seems to be a new bug where liquid flaking destroys the tiles above. Liquid flaking is simply a mechanism in which when a liquid touches a hot tile, it instantly evaporates 5 kg, ignoring thermal conductivity. See here for more information on flaking. So, 5kg of gas is generated by liquid flaking, but it seems to be a bug that if there is a tile there, it will be destroyed. In the OP case, liquid oxygen touches the relatively warm insulating tile on the right side near the ceiling, causing flaking, and the gaseous oxygen generated there destroys the metal tile above. This is my guess, but it's probably a new bug that's caused by fixing this bug in the test branch. By the way, this new bug seems to be able to be destroyed even with neutronium tiles. As far as I know, this is the second way to destroy neutronium in survival mode. (One of the methods is this or this.) One more thing, I said that a bug "destroys" the tile, but it's probably "pushing out" to be exact. If the surroundings are set to vacuum, it seems that there are cases where only the contents are pushed out and moved without destroying the tiles. (However, the direction in which the tiles are extruded may be random, so I'm not sure if this can be controlled intentionally.) Well, I'm not sure what it is anymore, but anyway, this bug causes unintended tile destruction and I hope it will be fixed.
  15. Due to this phenomenon, there is a difference in storage work speed. Maybe it's not a bug, but I can't tell, so I posted it to the bug tracker just in case.