• Content Count

  • Joined

  • Last visited

Community Reputation

16 Good

About TheDeamon

  • Rank
    Junior Member
  1. That was my thinking, a memory toggle would likely be able to address that particular need.
  2. Feed it to Arbor Trees, Thimble Reeds, or some Pincha Pepper plants, imo. It is exceedingly rare for there to be such thing as "too much reed fiber" for people mucking about in the late game.
  3. Tubes can be used by dupes with or without an atmo suit, but that obviously creates problems if you have a singular system and have a single unified tube station in your base(where no atmo suits are normally worn) and other tube drop off points in places that are very inhospitable to unsuited dupes. They're not going to appreciate being dropped into the hard vacuum of space with no return transport station available within easy reach. Likewise dropping them into a room full of 130 degree steam isn't going to be appreciated by a dupe not in an atmo suit. You can certainly make it possible to happen, but it's best to put measures in place to ensure it doesn't.
  4. I think he's wanting to know how to restrict dupes to only using the transport tube while in an atmo suit. To that question, the only answer that comes to mind is ensure every transport tube access point is behind an atmo suit checkpoint. Not 100% foolproof as dupes will still sometimes find (glitchy) ways past the checkpoint without a suit, but those occasions should be reasonably few and far between.
  5. I remember my Navy days working on RADAR systems that had a deionized water coolant loop which in turn was feed into a heat exchanger with the ship's (Salt water) fire main feeding it. High powered, and high value electronics do get directly cooled by water, for that matter, you need look no further than the guys running liquid cooling rigs on their personal computers these days, although they're typically not using water these days.
  6. Interesting find Crapig, I guess it partly puts a lie to what I posted elsewhere as I didn't try to stagger things, although I think you're actually demonstrating another aspect of the issue. It certainly does seem to be a timing issue whatever has been going on. I'm guessing a couple of the scenarios I outlined would be proven false quite readily with respect to the Conveyor Shutoff then.
  7. From my understanding, that changed with the .net framework change in the previous patch. People just didn't restart bases as a result of that one, so it went largely unnoticed.
  8. Minor usability tweak/note: The watt sensor only accepts numeric input values. However, after you've input a value it appends " W" to it, which will then need to be deleted by the user the next time they try to make a change.
  9. Issue is still present in the current beta build of the game. If a bypass is built into the Aquatuner's input loop, and a single packet of liquid is sent through the pipe. The aquatuner will activate before the liquid arrives in the pipe, thus sending the liquid through the bypass. So long as there are multiple packets of liquid, the second packet will be accepted by the aquatuner and function behaves as normal for subsequent packets. The first liquid packet always gets sent through the bypass. Obviously, not having a bypass installed "fixes" the problem, but then you no longer have a (safety) bypass.
  10. I was about to post a follow up on the ribbon problem. After switching the Or Gate in my previous Screenshot with an AND Gate configured as per my last post(adding in a switch that has been turned on to latch one input high on the AND Gate to buffer the NOT gate), my own Ribbon Problem was corrected.
  11. This is wrong based on testing I just did. The gates seem to function normally only so long as a NOT Gate is not the only thing involved in the logic tree enabling the result. Testing with an NOT Gate hooked up to an AND Gate which is in turn hooked to a Filter had these outcomes: NOT Gate High: Input 1 and 2 for AND Gate, Output high. Filter Gate accepts High, wire shows high. NOT Gate Low: Input 1 and 2 for AND Gate: Output low, Filter Gate accepts as high, wire shows low. NOT Gate High: Input 1, Switch on Input 2(High), Output high, Filter Gate accepts High, wire shows high. NOT Gate Low: Input 1, Switch on Input 2(High), Output low, Filter Gate accepts Low, wire shows low. NOT Gate High: Input 1, Switch on Input 2(Low), Output low, Filter Gate accepts Low, wire shows low. NOT Gate Low: Input 1, Switch on Input 2(Low), Output low, Filter Gate accepts Low, wire shows low. I'll let someone in a sandbox test nested Not Gates if they're crazy enough to do so.
  12. OR gates and AND gates are made for the purpose of reducing 2 inputs into a single output(favoring high signals or low signals respectively) without contaminating the two input signals(so they can be used for other things). That said, I wouldn't object to a Diode or even a "Line Filter" being introduced for filtering discrete input lines on a Ribbon. So we can segment the Ribbon without needing to break it out into X outputs(where x = 1 to 3) to feed most of it right back into a new ribbon. But first we need basic functions for it to work properly. My one Ribbon is also behaving oddly, only using 2 bits on it. If bit 1 is high, the whole ribbon renders as high. If bit 1 is low and bit 2 is high only bit 2 shows high. But for more interesting, with bit 1 high and bit 2 high. The 2 bit readers looking for bit 2 show high, while the bit reader for bit 1 shows low. With bit 1 high and bit 2 high, the ribbon renders as high, but bit 1 still reads as low, bit 2 reads high, so same as the above. Of course, there also is this graphical issue in play as well, the Bit Writter for bit 1 shows a green input, but the graphic connecting it to the ribbon shows a low.
  13. Already reported and being investigated. It IS quite the bug, even when the not gate reports a low, a filter gate and buffer gate will read it as a high, despite the graphics indicating a low is coming in. It pretty completely breaks a fair bit of automation for the moment. It appears OR Gates and AND Gates are not impacted, so a work-around is possible, assuming you have room to slip one into your logic circuit. :/
  14. Yes and no. In the case of a zoom, it likely just does a calculation based on the map location the click started on, and then uses the map location that the cursor ended on. Do not confuse the map location with screen location, while the two generally correlate, they're not the same thing, as you move the screen across the map in order to interact with things. The infamous selections when it's doing the autosave are more a matter of being based on start location plus movement data(at the moment of the freeze) to extrapolate where the cursor should finish. With the additional "bonus" of it not being bounded by what you can see on the screen(probably because it uses map location, not screen position). A possible "fix" that might annoy some players is possibly creating a sub-routine that cancels any area selections when those two events(auto-save, focus change) trigger. Just a matter of which poison you prefer in that case.
  15. "Mixed input" situations for the petrol generator would make it fail in prior versions too. I guess it is supposed to burn either Petrol or Ethanol, not a mix of the two. In the prior versions, I'd simply run the generator until it burned off what it could of the fuel I switched away from. Then I would connect the fuel I'm switching to. Normally that method would work without issue, but in the beta version they have out, even that methodology fails. Only by tearing down and rebuilding the plant was I able to resume power generation at that location. The plant has always left some fractional amount of fuel behind. It just now seems that the fractional amount of fuel can (at least some times) be enough to prevent the plant from operating again should you switch fuel types.