• Content Count

  • Joined

  • Last visited

 Content Type 




Klei Bug Tracker

Game Updates

Hot Lava Bug Reporter

Everything posted by kbn

  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.
  16. In my case, I had a little knowledge of computing, but I'm not a professional. I got used to it mainly by trial and error in ONI and playing other steam games. - Factorio - Human Resource Machine - 7 Billion Humans - SHENZHEN I/O I think the experience of these games that I have played in the past has also helped me to create ONI automation. Also, if you can play around with the Redstone circuit system in Minecraft, that experience may probably be useful. (Unfortunately I could hardly play with Minecraft due to 3D motion sickness)
  17. The disadvantage is that it takes about 0.5 seconds to display, but you may be able to simplify the display part a little by using bit shift. The ten Ribbon Writer next to the Signal Selector are the memory with the input and output connected. Each contains font data from 0 to 9. The binary counter circuit that combines AND and XOR at the top generates signals from 0000 to 1001 and operates the Signal Selector. The many switches on the right are the devices used to create the font data from 0 to 9 stored in Ribbon Writer's memory. It is unnecessary after storing the font data in memory. Save data:Abyss.sav
  18. I think the flaking is caused by the Abyssalite tile on the right. According to the wiki, the heat transfer efficiency of gas to solid is 25 times higher than that of liquid to solid. The hot steam heats the abyssalite tiles slowly, but the cold pw does not cool the abyssalite tiles. As a result, the abyssalite tiles slowly heat up, and when the boiling point temperature of pw is exceeded, it is presumed that flaking occurred.
  19. Yes, it's correct. I chose the ribbon lighter because it's kind of cool. Rather, from a practical point of view, I think the 0.1s filter gate / buffer gate, which can be made faster than the ribbon lighter, is better. No, the reason I use the XOR-gate / ribbon writer combo in the first image is that it needs to detect falling edges as well as rising edges. Falling edge cannot be detected only by Signal counter [count: 1, advanced mode]. However, the Signal counter / Not-gate combo can detect both rising and falling edges. (But it's better to use the XOR-gate combo than to use this)
  20. If you want to control the automatic dispenser with an automation wire, you need to supply power. However, the automatic dispenser is a facility that constantly consumes 60W when it supplies power, so some people may be a little dissatisfied with it. This method may be able to help those who are dissatisfied. When the power supply is cut off, the automatic dispenser is fixed in the open / closed state at that time. In other words, if the power is turned off in the open state, it will be in the open state all the time, and if the power is turned off in the closed state, it will be in the closed state all the time. (I believe this is the correct behavior, but is it a bug? Forget the information on this topic if it is fixed as a bug in the future) Use this to save power on the dispenser. In addition, the build below has a simpler structure, saving only the power consumption of the closed state. Perhaps in most cases, the purpose of controlling the automatic dispenser is to eject the accumulated items with a specific trigger. In other words, I don't think it's necessary to keep the automatic dispenser open, so this simple build will suffice. The automatic dispenser and power shutoff are controlled at the same time, but in reality there is a 0.2 second delay before the power shutoff shuts off the power supply, so the power is shut off after the closed state is reached. Therefore, it works without any problem. By the way, both builds guarantee a 0.2s green signal with a buffer gate. The reason is that the minimum 0.1s green signal does not supply power normally. At least in my environment it worked fine for 0.2s and above. It may be safer to set a slightly longer value (eg 1s).
  21. I managed to make it smaller. However, the placement of this sensor may be illegal.
  22. 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.
  23. 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.
  24. I think the door is normal. I haven't calculated it in detail, but I guess it's because of the heat transfer mechanism around here. https://oxygennotincluded.gamepedia.com/Thermal_Conductivity#Example_2:_Abnormal_temperature_barrier When I placed natural tiles with the same mass and temperature as the door (Wolframite) and metal tile (Steel), heat transfer stopped as well. However, this is unnatural at first glance, so even if the mechanism is normal, I'm not sure if it's correct as a game.