impyre

  • Content Count

    188
  • Joined

  • Last visited

Community Reputation

104 Excellent

About impyre

  • Rank
    Member
...

Recent Profile Visitors

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

Enable
  1. @Gurgel Okay, guy. I didn't say *I* was trying to be funny, I said I thought *it* was funny... your comment about memory I/O... your post as a whole really. Anyway, let's just agree to play nice and leave each other alone, cool?
  2. I doubt the sincerity of your apology. It was neither me being "obstinate", nor was it made in "good faith", nor did it require such a lengthy response. Also... it wasn't a question. I just thought it was funny, that's all. Why must you get all offended over it? Also, trying to sound like you know more than you actually do isn't really flattering... just saying.
  3. o.0? So buffers and caches are not memory? In any case, ultimately I do agree with your position. It's perfectly do-able. What we would be looking at would be a "meta" simulation. It wouldn't be simulating 6 colonies at a time, that'd be ridiculous... however, ONI already keeps track of your statistics for your colony on a cycle-by-cycle basis. It wouldn't be too hard to put something together that allows you to "simulate" a colony's inputs and outputs based on the averages calculated the last time that colony was actually opened. The only additional workload (besides whatever is loaded to actually enable this extra-colony functionality) would be simply maintaining a table of values telling the game what's being consumed and what's being produced. There are a couple of issues that arise though: 1) There's no perfect way to average outputs... no matter how you slice it, the system is "game-able". What I mean is that if you play a colony, you could store up a particular resource over an extended period of time, then initiate a "production" phase to fool the game into thinking that your colony produces more outputs for less inputs than what it actually does. The only alternative is to calculate the productivity on every geyser, every ranch/farm, etc and just assume it has enough dupe labor to function at 100%. (which leads to other issues, as well as cpu overhead) 2) This type of play doesn't make sense for colonies that have pretty much everything they need. This means you either need to completely redesign some asteroids to *not* have everything needed there, or limit the resources affected to the more rare space-age materials. You could have a thermium refining colony for instance. The second case requires specialized worlds to be created that are only available to colonies founded from within an existing colony. (which isn't a terrible idea) Another possibility is to have various geyser types that only appear on certain worlds... for example, an algae "colony" which produces algae, or a slime geyser, etc.
  4. Currently the Sous Chef position doesn't gain any mastery from cooking items. This was tested with the electric grill and the microbe musher. No mastery gain was shown at all beyond passive mastery gain.
  5. The port problem was related to the game allowing you to place ports in a way that could result in things not working, without it being clear why. They fixed it so the game no longer lets you construct things in such a way that the output port is obstructed. The text entry refers to typing numbers into the boxes for setting values. On some items, this has always been a thing... but a commonly requested feature was to add this to smart batteries and the like. @Pex @watermelen671 was just trying to be helpful, both to you and to the devs. There are literally a thousand things that can go wrong during an update. Files can become corrupted, perhaps the engine was changed to make use of new drivers for an optimization and your drivers haven't yet been updated... but that only affects users of certain NVIDIA cards... I mean the list is nearly endless. The point of troubleshooting the problem is to save the devs time sorting through "bugs" that aren't really due to problems in the code... it's nothing personal. I've worked in data centers (and produced code) for 10 years, and I can promise you that even I would troubleshoot first. No person can just *know* without a doubt that it *must* be the updated code failing. Proper troubleshooting is neither lame nor trivial, and I doubt you'll find any support here for that attitude... most of us here take supporting Klei seriously; the more support they get from the community, the better the game can become.
  6. @Serpher I don't think it works that way. It's either an input or an output. You *could* have both, but they would have to be separate ports. Input enables/disables tank, and output tells fill state. Enabling/disabling tanks seems kindof useless... because you generally use them because you want a buffer that's *always* available... why would you ever want to turn it off. Even if you did want to turn it off, using shutoff valves accomplishes this. You could also use a shutoff to automate the inputs and have the tank completely controlled by automation. The big deal here is having some way to easily check the fill levels of tanks. @Xadhoom It would be really nice to have a built-in sensor like the hydro and atmo sensors. Something we can change settings for so that it changes from red to green once a certain fill level is reached. It's nice to know when tanks are full because some systems don't handle being overfilled very well. It's nice to know when tanks are low because we can choose to activate secondary systems to help supplement our supply. (Like pulling nat gas from geyser storage if the gas from fertilizer, petrol, and oil production begins to run low... we want to use what we make first so it doesn't back up) Having configurable sensors make this easier. You *can* do it with vent-based sensors *sortof*, but it doesn't work great. Right now the most accurate way is to use a storage area combined with vent and mini pump, control the flow rate in and out, and monitor the fluid/gas levels, as that will represent the level in the tanks... but this sortof defeats the purpose of the tanks imo. edit: I tend to stay away from the pumps and sensors though, I use multiple tanks and pipe element sensors connected to filter gates, I get a signal when I'm down to one full tank left, and I have a full signal.
  7. I did that before posting about the bug. However, I also later experienced other problems with that save, such as darkness that couldn't be uncovered/revealed by dups. It was obscuring a natural gas geyser. I figured the problem was likely related to the save/map since it was freshly created with the new space industry release. Created a new map/save after the patch and so far this issue has not happened again.
  8. yes, this is definitely a thing... kindof exploity if you ask me, but also annoying. I had it happen earlier and I was upset because I always check and reject until i find one i like, then I leave it ready to print. It was gone after I had to reload.
  9. When setting the microbe musher to repeat a recipe, liceloaf in my case, it completes the recipe a few times and then stops working as intended. It still "works", but it's almost as if the chef or cook will ignore it. It sits idle until someone else has nothing else to do. Queuing up recipes individually works as expected, but the continuous mode doesn't. Also, once the breakage occurs, the only fix is to deconstruct and rebuild the machine. Once replaced it works normally for a time. EDIT: I don't have any logs to post, no crashes, or anything of that nature. The bug isn't one related to efficiency, slowness, or hardware issues, so none of that's relevant... and a screenshot simply wouldn't record the problem. I don't know if I can make a video or not, but that's the only way I can think of to really document the issue beyond simply describing it.