• Content Count

  • Joined

  • Last visited

Community Reputation

29 Excellent

About Dyrewulfe

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. Was just coming to post about this as well. Looking at your video, it's even worse for you than it is for me.
  2. This could also be a Unity engine issue(Which the Subnautica games, as far as I understand, also use.) If it is, then the best response from the Unity team would come from an issue being reported by a license buying, relatively high profile, professional organization such as Klei. @gportapuThinking on it, this is similar to a common issue I've seen in regards to games, where there's a selection issue when both an integrated GPU as well as a discrete option, present. I can't give any easy advice as to how(I'd need to research as well as have access to a similar and affected hardware setup), but completely disabling the integrated GPU may fix the problem.
  3. @simplesarcast Is Ellie injured here? If she's not injured, but can be assigned simply due to her medical skill(and thus goes to the cot and lies down in it for treatment), that's definitely a bug.
  4. @tommytom2k2 And I just popped in here planning to mention that exact thing! Seconding tommy, yeah, this is probably related to vsync. If the frame can't be rendered in less than or equal to 1/60th of a second(Depends on refresh rate actually, but 60 MHz is pretty common), then the frame has to wait until the next pass, so you only get half the refresh rate in frames. Also, as @SharraShimada mentioned, this game is very CPU intensive. Your GPU won't matter in the end. It may be worth getting used to it playing at 30 fps rather than 60 fps. In the long run(late game when there's a huge workload), 60 fps isn't maintainable(except perhaps on high-end systems with a solid single core boosting CPU). I play on a crappy HP laptop from 2010, with an abysmal integrated GPU, and it seems the late game lag is less of an issue for me... Why? Because the game always runs bad for me, so I'm just plain used to it, and it's less of a break from my expectations and muscle memory. TL;DR: The game's gonna run slow later on, unless you have a modern home version of the Gibson. Might as well get used to it. Edit: An afterthought I had. Your CPU is likely good enough to keep you at 30+ fps for a good long while. So, keeping that limit in place would probably give you a nice consistent feel to the play.
  5. No problem, glad I could help. Um.... Well, I had a handy bookmark for a guide about automation filters that I intended to share, but I had to wipe my browser recently to stop a crash-fest. Anyways, a simple filter like, while it works and demos the principle, isn't robust enough to trust in a real system. If any of the outputs in that get backed up(especially the final vent for the things not filtered), it'll break and you'll get gases where you don't want them. What ya really wanna use is what's commonly referred to as a "loop filter", which cycles the filtered gases around the loop until the proper output is available again. If you have any trouble finding info on them(lot of guides and tutes around though), I, and many others who can help, are on the unofficial Discord: https://discord.gg/EBncbX2 The pipe mechanics are really counter-intuitive, and worth some research or questioning about, even if you're like I am and prefer not to spoil the sense of discovery and learning for one's self. And I suppose since that's already a wall of text for bug report standards, I'll sign off with a pic. This is the layout for the "this gas here, everything else there" type of loop filter, akin to what @Gwido mentioned. Both sensors in this case are set to the single gas type you want to pull from the line.
  6. @npjohns If you're seeing gas go past the filter example I made, then there's some specific that's wrong on your end. That filter setup works just fine on my end. Are you playing at the debug 10x speed or something? Edit: Okay, well, it works fine until the power setup you had on that sandbox failed. Another edit: I corrected the power issue, and the filter system works just fine. So if it's not working on your end, then there's definitely something going wrong that's not affecting most players. I, and many others, have been using automation based gas filters successfully for quite a long time. Also, wondering what you're talking about with pipe intersections? There aren't any standard pipe intersections in that example... It's just a straight line of pipe with shutoffs connected to it. I did some modification so anything that might be failing to get filtered would be visually apparent: No natural gas is getting past that first shutoff(granted, it will if the output vent gets backed up, but that's an entirely different issue altogether)
  7. I've had this happen to me just due to the UI lagging out, leading to a an unintended, and not easily correctable, result. That's "bug" level in my mind. And last I saw of the suggestion sub-forum... Well, let's just say if it was me, I doubt I'd be spending enough time digging through there to find an issue like this. This isn't "suggestion about gameplay", it's an actual PROBLEM.
  8. @SharraShimada Might not be a "bug" in the traditional sense, but it's still a serious user experience issue. It's terribly easy to accidentally misclick a skill, and the respeccing station is not instantaneous(in fact, it consumes quite a bit dupe time which one might not be able to spare at all in the early game.) I'd personally say it's an issue worthy of reports. A simple confirmation request when applying points would be a good thing.
  9. ACk... Followed the link to the previous bug report, and posted there... Anyways, I re-uploaded your original save(in the link bug report) with a demo of how to make it work properly.
  10. The automation for gas filtering works fine, but you're expecting the sensor to do gas routing, I guess?(just going by how the setup looked) Pipe element sensor in conjunction with shutoffs need to be set up so that the gas flows directly from the sensor pipe section, to the shutoff input. I've reattached your save with a demonstration of this added in. 5b89e3ebde86f_TheNeedyMoonbase.sav
  11. These things are really pronounced on my aging computer rig. From what I can see, it appears that the critter drop-off has to issue the errand to relocate the critter after it's wrangled, and this doesn't happen before the wrangling dupe looks for their next task. The only time I've seen this work like it should, is very early in the game, when the critter immediately switches to "Trussed" status. Later on when things get laggy, it can takes up to 15 seconds before the critter updates it's state, and a relocation errand gets generated at all.
  12. That's actually a somewhat low amount of food poisoning. Did some rough math, you're only going to have about 1300 germs in each 5kg unit coming out from the sieve. And food poisoning starts dying off at 40C. The germs may just be "dying off", due to low population, while in transit to your clean water storage.
  13. Only reporting this since there's clearly been work done to provide backwards compatibility with older saves in regards to the new skills system. Interests are not currently being ported over to the new system.
  14. I've seen this kind of thing before. Every once in a blue moon, something that gets dropped turns into a tile, rather than a pile.
  15. They'll also pretty much never work on a bridge input port if the liquid is flowing, even if the bug here for the output side is fixed. Bridge inputs pull the fluid out of the pipe before the sensor gets a chance to trigger on it(and that behavior is actually extremely useful, please don't change it!)