• Content Count

  • Joined

  • Last visited

Community Reputation

16 Good

About Interloper

  • Rank
    Junior Member


Recent Profile Visitors

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

  1. Dang, and I was trying to be so careful with my math. But from the testing done by @Risu and @supo92, it does appear that there is an inconsistency in the flow calculation.
  2. It's a commonly encountered bug that pumps, pipes, and liquid vents destroy liquids. For example, a loop consisting of: pump1->pipe1->vent1->back to pump1 will slowly destroy the entire contents of the tank. I did some testing to determine whether this was caused by the pump, the pipe, or the liquid vent, or some combination of both. I believe that the pump that is destroying 1.06% of each water tile. My test methodology is shown in the attached picture. One tile of water is 1000 kg. Each packet of water that flows through a pipe is 10kg, resulting in 100 packets per tile of water. Using the debug tools, I created a pump with a 100-tile long pipe and an output tank. To test the liquid vent, I filled the pipe with 100 packets of water (approximately 1000 kg, or 1 tile), and removed any extra water from the input using the debug tools (The pump and vent must be connected for liquid to flow in the pipe. I measured the volume of water dumped in the output tank, which was 6 squares of 165.5-167 kg each, or approximately 1000 kg, which is about what should be expected. Next, I destroyed the entire system (to delete any water stored by the pump or vent). I put 1 tile of water (1000 kg) in the pump, and disconnected the outlet when all of the water had been consumed (see picture). While 1000 kg of water was available, the pump left 62.2 grams (intaking 999.9378 kg of water). The pump put 101 packets of water into the pipe. Each of the packets were 10 kg, except for 5 packets, which were 5 kg (#51), 7.5 kg (#63), 7.5 kg (#73), 7.5 kg(#83), and 1.825 kg (#101). Thus, for reasons unknown, a total of 10.675 kg of 1000 kg (1.0675%) of the water tile was missing. Noticeably, three of the five occurred every 10 packets (#63, #73, and #83). It would appear that for some reason, the pump does not always grab all of the available water, or destroys some of the available water. I tested the pipes for leakage using a liquid filter and series of pipes that looped contaminated and clean water in a closed-loop without a pump or vents. It did not appear that fluid was created or destroyed. I hope this testing is helpful in narrowing down the issue causing this. The save file is attached. Testing.sav [Edited to correct math -> 10.675/1000 = 1.0675%]
  3. Interestingly, given the same conditions but using contaminated water, pumps did not drop contaminated water bottles or normal water bottles (but still destroyed the contaminated water over time).
  4. I set up liquid pumps to test pumping liquids back and forth. I observed that, over time, the left-most water pumps periodically drop 10kg bottles of water. This should not occur - either the pump should draw water from the tank and insert the water into the pipe, or not perform any function. The pump should not draw water, bottle the water, and drop a bottled water object. The pump placement within the chain with respect to the outlet vent does not matter, it is always the furthest pump to the left. I'm just guessing at the code, but it seems as though the game checks, starting from the left, whether each pump has a liquid to draw from, but does not check to see if the drawn water can be stored in a pipe or the pump's storage until after the pump has drawn the available water. If there is no room in the pipe or the pump's storage, the excess water is dropped as a bottled water object. If the code actually works this way, then the pump should either check to see if water can be input in the pipe before drawing water, or the dropped overflow object should be a tile of liquid water, not a bottled water object. As an aside, the water level of the left tank originally was half-full (marked by the dirt block located mid-left of the left tank and right of the mesh tiles in the mid-left of the picture). Over time, the water disappeared from the system. I am unsure as to whether this is due to the pumps, the pipes, the outlet port, or a combination of the three. I think this bug is commonly known and reported elsewhere. A save is attached. Testing.sav
  5. Currently, liquids do not boil when exposed to a vacuum. In real life, as pressure decreases, the boiling point of a liquid decreases. For example, when exposed to a near vacuum, water instantaneously boils into a gas. This probably arises because the game models solid/liquid/gas matter phase change by determining solely the temperature of the object, and assumes the atmospheric pressure is fixed at 1atm (e.g., the pressure at sea-level). However, the phase change is actually a function of both temperature and pressure. I debated whether to add this as a suggestion or a bug. Because the game models temperature, matter phase change, and pressure, I think the lack of interrelated behavior is probably an oversight or bug.
  6. Batteries can heat surrounding materials, such as gases, to temperatures hotter than the battery itself. For example, in the below screenshot, the batteries are encapsulated by insulated tiles in a closed room. The highlighted battery has heated to 126.9 C, but the surrounding gas has been heated to 140.2 C. The battery should not be able to heat surrounding materials hotter than itself. This violates the second law of thermodynamics because heat is flowing from a colder object to a hotter object. Rather, the battery and the gas should rise roughly equally in temperature over time because as the battery heats, it should transfer heat to the cooler gas, causing the gas to rise to the temperature of the battery. A save file is attached. This bug is classified as an exploit because it can be used to melt or evaporate materials that have much higher melting or evaporation points than the max temperature of the battery. Testing.sav
  7. This is related to this bug: A temporary workaround is to use a higher screen resolution. Try setting a higher resolution, closing the game entirely, and restarting.
  8. First, this shouldn't occur because it is unexpected behavior. It is unexpected because logically, the player would not plan for a Dup suffocating himself by building a tile over himself (and the game should not be expect the player to be aware of this). Further, once the user is aware this can happen, the user cannot adjust his gameplay to prevent the behavior. In most cases, Dup movement is controlled by the AI, not the player. While the player has a "move to" command, this should be an exception to normal gameplay and not a requirement to prevent Dup death during building construction. The user should not be expected to micromanage the placement of each Dup for each individually constructed tile to avoid the Dup dying. The focus of the game design is on macro-management and emergent behavior. In contrast, micromanagagment should be handled by the AI. Where the AU results in bugs in pathfinding and positioning during construction, the AI should be fixed. I agree. I think there is a clear distinction between "dumb user commands," such as giving a Dup a command to remove a floor that he is standing on, and "bugged AI pathfinding." The "Dup suffocating in a tile he built over his face" is an example of bugged AI pathfinding.
  9. Bugs 1 and 3 are bugs - if the Dup is stuck but a potential path exists, his pathfinding has a bug. For Bug 1, the Dup should still be able to clamber up. For Bug 3, the Dup should not be stuck mid-air. As to Bug 4, if this is a rounding issue, then the display should round *down* instead of *up* to avoid giving confusing and inconsistent info to the player.
  10. I can confirm this has happened to me too. This is meets the definition of a bug because the Dupes should not be able to suffocate themselves when given an ordinary 'build tile' command. The pathfinding should move the Dupes out of a tile they are currently constructing to avoid unexpected suicides. Getting trapped behind walls is another story. I agree with you that the player should watch out for accidentally walling Dupes outside the colony.
  11. Can you post your save file or at least a screenshot?
  12. I also have this issue. Water tends to disappear when flowing.
  13. If you select 1024x728 screen resolution, upon starting a new game, the Dup selection screen does not scale to the correct size. This results in truncating the left half of the left-most Dup profile and the right half of the right-most Dup profile.
  14. Bug Submission Please choose a category [Exploit] Platform [*]Steam Version Number 73726 Issue title Adding items to full stack increases freshness Steps to reproduce 1. Have a full stack of half-spoiled food (Ex. 20 Monster meat at 50% spoliation) 2. Have a second stack of fresh food (Ex. 11 Monster mean at 90% spoliation) 3. Repeatedly add the second stack to the first stack. The full stack's freshness will rise a bit with each click until both stacks are at 90% freshness. Describe your issue With each attempt to combine the second stack with the full stack, the full stack's freshness will rise to match the smaller stack's freshness. This occurs even though the smaller stack is not combined with the larger stack. This results in freshness generated from nowhere and allows one to increase a large stack of food's freshness with no penalty and thus perpetuate a full stack's freshness.