darknotezero

A while back I posted my version of a clock/timer that I was using to accurately track geyser active/dormancy periods using a very simple water clock and a lot of automation: Your use of pixel blocks is much much more elegant looking and has the added bonus of +decor, so i might try to tinker around with that. If you're not already familiar with the issues of long-term clock tracking using buffer and filter gates, make sure you know about it, and do a search for water clocks.

if, for example, i've dug out a huge swath of tiles of varying types and all of the debris exists in one level of the ground, it would be nice if i could do a drag-select sweep action but select only one type of resource to sweep. what brings this to mind is my shove vole farm. regolith that falls from my rocket shafts are usually mixed in with artifacts, data banks, and other stuff that meteor showers might toss around when the bunker doors are open. Regolith also gets carried and occasionally dropped by dupes on their way to use them as filtration material. I want to be able to pull back on, say, the whole map, drag the entire map with a sweep command but have it only select regolith.

will those who bought early access still have to pay full price for final release?

uninstalling and reinstalling the game has fixed this most of the time. For me, i did that, cleared cache, and a few other things, when i booted up ONI it crashed immediately, but then when i tried again it opened fine. This has also been reported in the bug forum in multiple instances, so you might want to go searching there for any exotic answers if uninstall/reinstall doesn't do it for you

seconded

i was able to resolve the Mac OS error by uninstalling and reinstalling. I copied the save files folder and retired/archive save files folder just in case but it did not end up being necessary. After reinstall, the first attempt to open my save file crashed immediately, but the second time i tried it it worked. I did send the crash report via the game's internal engine. fwiw, i also did a lot of the troubleshooting steps from the Steam troubleshooting page before reinstalling - i don't know if any of those helped, but it can't hurt.

ME TOO. i'm still heavily invested in Apple and like what they do for my purposes (been using them for almost 30 years now) but when they started to steer all of their computers both laptop and desktop towards nonupgradable or replaceable, i was pretty unhappy. I think they realized that with the Pro line when the trash can mac failed, but then they went all extreme with the new Pro. It'd be nice to have a more entry-level Mac that doesn't cost an annual salary that i can upgrade the internals myself.

blobs stutter for me in overlays when my dupes are doing pipe construction/deconstruction. like, the animation of pipes being added/removed causes a graphic lag that the game auto-updates the pipe flow animation to compensate for the offsync of game ticks That to me feels separate from a stutter due to performance issues.

i would estimate a more accelerated timeline than that. 3-5 years would be my guess? I may be investing in the new M1 MBP. I hate being an early adopter and would rather wait until M2, but my current MBP's speakers are blown and it doesn't feel worth it for me to get it serviced or to try to service it myself since it's several years old at this point. a part of me also would love to get a new desktop (not that insane MacPro but the iMac pro) bc i much prefer desktops to laptops for high CPU things i do (video editing, realtime audio/video manipulation, and let's face it, ONI), but the practicality of having to take a bunch of that work on the road has made the sacrifice of laptop performance worth being as mobile as possible If I do end up getting the M1 MBP, i'll def be playing ONI on it, and will likely post up comments/thoughts/comparisons about ONI performance on it vs what i use now.

something to consider about the change from intel to Mx chips is the distinction between optimized vs non-optimized software execution. Native Mac apps and other 3rd party apps quick to the draw will have redeveloped their software to take advantage of how Apple has changed their architecture and optimize accordingly. But that's not a simple task - Adobe has apparently stated that it will take around 6mo or so to make photoshop run natively with the new chips as opposed to it being built 'the old way' but still working on the new Mx chips because they get translated by an internal apple process (i think it's called Rosetta). Point being that chances are ONI will run faster bc the chip set is better, the whole machine is more efficient and etc., but it won't see the same sort of gains that you'd see out of native Apple apps until Klei redesigns ONI to run natively for the Mx chips and Big Sur.

My position on this is: this is a bug, but it's not worth fixing outside of a Major Update way in the future. If what gkbrew stated in my other thread that brought this up is true: then trying to fix this bug is not a small fix as it changes a fundamentally base behavior of the way they designed the automation that would likely have ripple effects throughout the game. Given that there is a reliable and fairly straightforward workaround that *does* offer precise timing, i'd rather the devs work on other things with the limited resources that they currently have and not get stalled trying to fix this and then also fix what will inevitably break by trying to fix this. Short burst or non-precise single cycle timing is where this stuff shines. When you need something more, use a water clock. problem solved. Let them fix the stuff that can't be fixed and/or work on finishing that Space update.

forgive my ignorance, but what do you use the resulting fluid metal for?

i'm not an engineer, but this describes the way i play this game to a T, especially when it comes to temperature management. I'm definitely still hacking my way through that fairly clumsily. Anyway, as someone who defines myself as a bumbling intermediate player, I have to say that the fandom ONI wiki guide on Base Cooling was definitely an important resource for me to start when I didn't really understand any of the numbers or the fine mechanics of the game. I definitely did a lot of clumsy pipe running into cold areas with radiant pipe to chill my hot liquids/gases (and warmup those cold biomes as a result) that would loop back into my base that started to get too hot. My base still got hot over time, so it was more like turning a gushing open wound into a slow death instead, but it still helped me start to grasp how to do it better when I started my second colony. Once you start to understand how that works, the numbers and the detail/nitty gritty starts to make more sense, especially once you understand how to use Thermal Capacity, Specific Heat Capacity, and "state change" points in elements (melting point, evaporation point, etc) to deal with temp management. It might help to know when in-game you're starting to get heat death. Like, if you're dupes are dying by cycle 100 due to heat death, i'd venture to say that you're running too much hot machinery? if you're talking cycle 500, that's something else entirely.

basically. The counter counts upwards in tenths of a cycle, and then automatically resets when a desired number is reached. In this context, i have it duplicated so that the counter can reset based on two numbers: active period of a geyser vs dormant period of a geyser. So i have to know the numbers i'm targeting; it'd be nice if there was a count backwards feature, but i'm rolling with the cards i'm dealt. it's not really *necessary*, but it's a fun project for me and makes easier some of the stuff i have going on in my base. I'm drawing water from two cool steam vents and natural gas power from two natural gas vents. being able to see in one place where they are in their active vs dormant periods so i can track my heavy saturation periods (where both like-geysers are active) or heavy dormant periods (where both like-geysers are dormant) is useful data that i'd like to be able to see easily. I am starting to think about it for more long term practical purposes, say, for a process that I want to turn on for 20 cycles and turn off for 5 cycles. I know that there are water clock solutions to this that don't rely upon display automation, but a) i wanted to tinker with solutions that used zero power and the one water clock solution that I found that used zero power wasn't working for me, and b) i'm fairly obsessed with dashboards that display relevant information all at once in a single glance. i have this picture in my head of a single area that displays all of my active/dormant geyser periods in a nice row. Granted, the amount of resources and real estate that my solution takes up is pretty obsessive, so actually putting this into my base is still a question mark. but it was a fun thing to put together and work through the kinks.