• Content count

  • Joined

  • Last visited

Community Reputation

100 Excellent

About Supraluminal

  • Rank
  1. R1...AT...R2 R1 = reservoir before AT that receives returning liquid from cooling loop; R2 = reservoir after AT; AT = you know what it is To get a precise temp out of R2, put a temp sensor directly after the R2 output. If the flow is too warm, route liquid from R1 -> AT -> R2. Otherwise cut out the AT and pass liquid directly from R1 -> R2. (R1 doesn't even have to be a reservoir necessarily, it could just be the return end of your cooling loop.) You can add more temp sensors in various spots for failsafe operation around some edge cases, but in general this is a super-simple way to fine-tune the output temp from an AT. Maybe I'm missing something, but I don't think the complicated mixing scheme gets you any other benefits.
  2. Checkpoint for supply

    A...D........................Z..................B D = dupe, Z = supply destination; A, B = materials It's not a trivial problem to solve. Either rule (get materials closest to me/closest to destination) can result in absurd-looking behavior. The "nearest to destination" rule would have the advantage of being easier to build around predictably, though. You can't really control where a dupe starts an errand from, but you can store materials near the places they'll be needed. It's the rule I would choose, if I could. As to why it is the way it is - maybe Klei found in testing that it wasn't a big difference, or maybe it was easier to implement as "nearest to me" for some reason. Or maybe it was something they slapped into place without thinking through all the implications, meaning it wound up this way essentially by chance, which is something that happens often enough in software development.
  3. Electrolyzer setups

    I have more questions: Why is 100% uptime important if you can just build slightly more electrolyzers to meet your targets? How/why is hydrogen destroyed? What circumstances cause it and how do the more advanced layouts prevent it? Why do you want to avoid filtering, bearing in mind that this can be done with little to no power requirement? Why do you want to avoid storing gas in a separate area? Pumps sucking less than 500g/s can be mitigated or eliminated with very simple automation, or am I missing something here? I know that part of the appeal of ONI is designing the most elegant, compact, and efficient systems possible just for its own sake, even when more basic systems would be perfectly functional. Is that the main motivation here, or are there significant mechanical benefits to the more advanced electrolyzer systems? To be clear, I think "because it's a fun challenge/because I felt like it" is a perfectly fine reason to do something, this isn't intended as an argument against the more complex designs. I'm honestly just curious about what mechanical advantages there are, if any.
  4. I just asked about this the other day in another thread and it seems that since they revamped the turbine, this no longer provides any benefit. In fact I think you want to do more or less the opposite - cut off the flow of hot coolant to the steam chamber if the steam temp exceeds 200C. My understanding from the wiki is that the turbine will consume steam at a steady 2kg/s and delete 90% of the heat it contains, with the output water pegged at 95C. It generates power at a fixed ratio to the heat deleted (about 1J per kDTU), up to its max output of 850W. Any heat above that is "wasted," i.e. deleted without increasing the amount of power produced. If you're mainly using the turbine as a cooler that's fine, but if you want to maximize the power you're generating it's something to watch out for. (Running the turbine at lower temps is fine BTW, since the ratio of power produced to heat deleted is not dependent on the temperature of the steam.)
  5. If they ever do make combat a real part of the game (through aggressive critters or otherwise), I hope it's optional. I don't have any desire for combat in ONI, partly because it's not thematically interesting to me and partly because I doubt that it could be implemented in a fun way. As it stands the game is just not built to handle situations requiring precise real-time control over dupes. I think anything other than very light, non-threatening combat mechanics would end up as an exercise in frustration. Environmental hazards and fires could be interesting, but like any new feature a lot would depend on the details of how it's built. For example, I would not want to have to micromanage the maintenance schedule of every building in the colony. If you can find a way to add the risk/reward mechanic (spend time/materials on fire prevention, or accept higher risk so I can spend them on other priorities) without bloating the game though, sure, that might be fun. Even then, it needs to be balanced so that it's not either a mandatory resource sink that you unthinkingly fulfill or a non-threat that you totally ignore - it would need to be a real choice, one that you have to actually weigh and revisit periodically as you play.
  6. Thanks for confirming this. Although unrelated to this thread, I've started using shutoffs a bunch in my latest run and was starting to suspect they weren't actually drawing power. Good to know. I wonder if this is a bug or just a weird design decision/UI failure. I'd be happy if they dropped the power connection requirement, personally.
  7. Huh, cool. I've been reluctant to get into modding ONI (it's already a huge timesink of a game and my potato computer can barely run it as is) but I might make an exception for better storage options.
  8. I'd love to see the Smart Storage Bin and the Refrigerator updated with high/low threshold settings a la the Smart Battery for the auto output instead of the single full/not full setting they have now. It'd make it easier to implement various automation schemes. On a similar note, I'd also like Smart variations of the liquid and gas reservoirs with the same threshold settings. Finally, I think a lower power requirement would be in order for the smart bin (and any potential reservoirs). 60W constant draw seems high for a simple sensor - in fact, unless I'm mistaken this is the only sensor in the game with any power requirement. Drop it to 10W or eliminate it, IMO. The smart bin is already more costly than a regular bin since it takes refined metal to build.
  9. [Game Update] - 259633

    Ugh. Why would you do this! It was really useful for building efficient storage setups, and also had some use as a way to gate off duplicants from getting at certain containers that you only wanted sweepers to touch. Can they still deliver materials through solid tiles? Did this only affect picking up through mesh and airflow? It would be nice if you'd clearly state what the intended behavior of sweepers is so we know what we should actually be expecting. At this point I don't know what is or is not a bug I should report.
  10. That's pretty much what I meant by #2, yeah. Known issues, intended to be fixed, but maybe not high priority while large features are still being added/changed. Certainly a possibility.
  11. I don't mind at all that some players happily use the drip cooling trick or other quasi-sketchy heat-deletion methods - it's a single-player game, do anything you like - but you've got to acknowledge this isn't useful as a defense of those things as such. It's not as though the current balance of heat management options in the game is a fact of nature; if Klei wants it to be possible to handle heat without the bugs and weird tricks, it's well within their power to make that happen. Which really leaves us with the question of why heat is balanced as it is, and how it might change in the future. I can imagine a few possibilities: 1) The drip cooling bug is, for some reason, incredibly technically costly to fix. Klei doesn't like it but would rather ignore it than deal with it, and is just choosing to keep mum because sometimes that's best for PR purposes. 2) Drip cooling and fixed-temp machines are artifacts of the early-access phase of development. Klei plans to fix/change them and move to a more internally consistent thermodynamic model. 2a) These things are bugs and hacks that Klei has put in as patches but lacks the time/resources/ability to resolve coherently, so are here to stay in some form. 3) Drip-cooling, fixed-temp machines, etc. are intentional mechanics. Klei has balanced the game around them and intends for players to use them liberally. For whatever reason, they don't want to make a clear statement to this effect. As a software developer, and having played computer games for 25 years, I could easily believe any of those.
  12. If it's neither of those things, then it's at least a really confusing and opaque behavior of the game. It seems like there's a couple of threads every day of people posting various cooling setups they're proud of creating only to be told that 80% of the thing's cooling power is due to the drip cooling behavior. If it's intentional, it should at least be possible for players to easily identify when it's happening, to understand why and how big its effect is, and (arguably) to avoid it if they'd prefer.
  13. I still see this issue as of OC-256131. Smart storage is usually not filled to max capacity by dupes or sweepers, and even when the UI shows that it's full, it will occasionally not output a true signal. In my experience so far I can always get it to output true by setting the max capacity lower than the currently-stored amount of material, but obviously that's a lousy workaround. Here are two shots of a smart compactor showing 10t of granite stored. Set to 10t max, the output is false; set to 9999kg, output is true. The regular compactor to the top right contains another 9t of granite and is set to lower priority, so if the smart compactor were a nanogram short or whatever, the sweeper should top it up - but it doesn't. (This is the entire point of this arrangement in fact; it's part of a system to automatically maintain a set quantity of material at a remote supply depot.) I would speculate that the compactor showing a full 10t stored is the result of rounding and that the actual amount is some tiny fraction short, but that's something for a dev to verify. If you want to check this specific building, it's at the bottom of the base in the attached save. I hope we can get this bug fixed soon. It seriously limits the possibilities of what you can make with the conveyor systems. The best outcome in my opinion would be to rework the smart compactor/fridge to use separate max and min capacity sliders like smart batteries. Players will probably most often want to use these buildings to implement a hysteresis loop of some kind, so make it easy on us. (Honestly I think you should do that for every sensor and building where it could possibly make sense!) Fool's Hope.sav
  14. Auto-Sweeper range/occlusion inconsistent and confusing

    Not sure if you posted before/after I edited, but note that I went back and replaced all the floors with airflow tiles, and as suspected the sweepers could then reach all compactors. So between that and your observation about diagonal openings (which I've noticed dupes can see through) it seems pretty definite that the LoS of the sweeper is the limiting factor. My preferred resolution would also be to remove the LoS requirement and allow sweepers to pick up from anywhere within their range, as this seems to be one of the biggest things differentiating sweepers from dupes. It allows for interesting designs that rely on closing areas to dupe access. Failing that, if the devs want to keep the LoS limit in some form, it needs to be communicated clearly in game. The simplest way to do that would be to restrict both depositing and fetching by sweeper LoS and then update the range grid behavior when placing a sweeper to properly account for that. But, that would be a significant downgrade to sweepers which seems unnecessary and un-fun to me.