kbn

  • Content Count

    112
  • Joined

  • Last visited

Community Reputation

286 Excellent

About kbn

  • Rank
    Member
...

Recent Profile Visitors

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

Enable
  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. I think that's a little different. The only thing that doesn't get wet by jump teleport is the duplicant. The high temperature material carried by the duplicant will boil the liquid in the three tiles due to its heat. Also, as for carrying volatile materials, I don't think that volatile materials carried by duplicants emit gas in the first place. (It would only release gas after the Duplicant let go of it and dropped it in the middle of the journey. However, I personally agree with Nakomaru's logic. Since the duplicant doesn't get wet in the jump teleport, it seems to me that the correct mechanism would be for no heat exchange to occur. Well, I suppose it's somewhat pointless to talk about the correct mechanics of jump teleport, but...
  4. 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.
  5. Excellent work. I don't understand the core of it at all, but I played with it a bit, looking at the bits of information stored in the 16 bytes of RAM and the opcode in the quicklist. There were two things that looked like bugs. First, there is a misconfiguration in some of the ribbon readers that make up the RAM referenced by RAM address "1110". Second, there appears to be no difference between code JLT and code JLE. I think the program code for the 6th step with JLT is in RAM addresses "0111" and "1000", but the inside view of RAM address "0111" is "00000110". In the quick list, "00000110" is JLE, not JLT. I don't know if it's simply a mistake in the quicklist or in the contents of the RAM, but for now I rewrote the contents of RAM address "0111" to "00000100 (JLT?)" and tried to run it. During execution, I kept an eye on the memory toggles that make up the AX registers, but both JLT? and JLE? counted up to 10. So there seems to be no difference. If it is JLE, then the AX register should count up to 11, so I think something is bugged. Note that my knowledge of assembly is almost entirely based on information I got from a game called "SHENZHEN I/O", so what I'm saying may be completely misguided. I'm sorry if I'm wrong.
  6. 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.
  7. Good pick up. The fact that 15.10kg > 15.9kg is very strange.
  8. It disappears when the lower body of Dup passes there. It doesn't seem to disappear when passing by climbing a wall.
  9. 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.
  10. There is a solution in the comments here. However, I think it is a bug that this unknown area is generated.
  11. 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
  12. 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.
  13. 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
  14. 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.
  15. 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.