• Content Count

  • Joined

  • Last visited

Community Reputation

21 Excellent

About riwenna

  • Rank

Recent Profile Visitors

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

  1. It's not precise, but if we're just answering a yes/no question (do cirtters that can not move take up more processing power than the ones which can), you don't need that much of a precission. A bit more finnicky way to do it but possibly more precise as it would cut down on other actions would be to let all your critters in a single stable go 'glum' (by denying access to ranchers), and then lock a Rancher with them and check how long it takes a rancher to groom a full stable of critters and go Idle? Another two actions that seem to be slowerd down is calling Dreckos for shearing (I guess could be tested the same way but that sounds a pain, waiting for all of their scales to grow back up), calling critters for a wrangle in stables with autowrangle (this could be a bit simpler as it wouldn't require waiting time - if you have an empty stable, try relocating all critters from a full stable to an empty one and measure how long it takes), but maybe even more precise could be critter dying time (as with grooming/shearing/wrangling, you'll actually be measuring two times; the time it takes for a critter ro register it's being called (which we want to measure) and then the time it takes for them to walk over (which we all accept based on our ranch designs), plus relocation time with wrangling. I've noticed that when culling my Shine Bugs, all of them died with exactly the same delay. Actually I go back on this theory (and here I am doing exactly what I said I wouldn't and guesstimating how the game works based on a code I never saw)... Since mass murdering a bunch of critters on a single tile (which are in no way "consecutive" - you can try this by randomly attacking 10 of them rather than the first 10 in the selection queue) causes them all to die with exactly the same delay, it would seem that order of processing cirtter commands is somehow "fixed" rather than chosing which critter/action to process at random). The same is true when printing a pack of Pacus from the pod, they all hover in the air for exactly the same amount of time, before realising they should fall down, and similarly which direction to flop to get to water (although since they are printed together those could be in many ways "consecutive" critters in memory). This seems like an approximately the same amount of critters I have at the moment (actually, it seems to match my number of movement restricted/free moving critters very closely). My map currently reads about 420 tame critters (about 380 movement restricted), plus about 130 wild ones. And you Dupes seem to be interacting with critters as well. Drecko shearing is done less frequently than grooming, but I'm only grooming about 40 rather than ~100 critters. How are your delays with shearing, do they seem responsive to the Rancher calling them? In your case, it seems to be a bit of a case of "Doctor, it hurts when I do this. - Than don't do that. - But I like doing that. So I'll tell others not to do it and continue to do it myself." But considering cycle ~5000, seems like you might have a machine that gives you a bit more leway, so good on you. You seem to like your ranching-based economies as well (I though I was the only one doing Oxylite with Pufts, designing that to auto-regulate prices and breeders was a nightmare and then the update ruined my savefile...), I would think you could relate to people trying to run different parts of their bases on critters.
  2. I interpret what you said more like this: #1 pick (random?) critter from movement queue #2 try moving random direction - yes? remove from queue - no? return to queue #3 return to #1. So if all critters need to be "processed" before the next round starts (and/or get pushed back to queue at every tick), then I could see how a critter unable to move might keep getting added to the queue indefinetely and slow everything down to a halt. On the other hand, if no critters were 'blocking' the queue, this would result in a fairly random and sporadic movement patterns rather than straight lines. On the other hand, exactly this. If critters with nowhere to move (as opposed to 'trapped in a tile') take more computation than non-trapped critters, then the computation should be adjusted coz that can't be good. Yeap, this would be a way to test it. A two-room farm might even be sufficient (after all, in a 3-tile, the situation improves in only 1/2 cases, as the critter will always move from a corner tile (with only 1 movement choice) to the middle tile (2 movement choices) and then to a corner again (same or different one), so improvements should already be visible in a 2-tile room). Any chance you could modify your design to try this @Zarquan, with a 2 or 3-wide room instead of trapped in one tile? I would but the Bug-Solar is just a big ball of 'Intensely bright' that I navigate on the materials overlay and using the screenshots I took when it was empty, so I don't see a way to modify it with the critters still inside (and I'm not an expert user of debug mode either...). Besides, after my little lights out cull, I believe you are now left with more critters on your map/tile
  3. So... after lights out for all the surplus Shine Bugs in that solar panel setup, and reducing the number of domesticated critters from 742 to 415 (out ot which 388 shine bugs... 8 in the main stable and 380 powering 8 solar panels total)... it takes a critter 30 seconds to realise it is dead on 3x speed :/ The Ranchers still seem to be having a hard time getting a critter to hear them whistle, but there seems to be somewhat an improvement to that (and to the fps...). I could probably increase the Bug/kW ratio a bit by using the original 3-panel design instead of a 4-panel (since in my modified 4-panel desing the last panel gets only one tile of light, it takes many more bugs to max out the last of the panels)... and I don't even think it's a particularly "evil" or "exploitative" design - Shine Bugs give light. Solar panels turn light into electrical energy. This game is all about turning one type of resource into another one... it screams "put us together". Last playthrough I had... most of my resources obtained "organically", and all the critters ranched for material conversion. This seemed to be the next logical step, it really is a shame it makes the rest of the critters on the map so sluggish.
  4. Sounds interesting. Now if he only... removed the modded half :P But I really do like his shine bug solar power plant design, can't help it. I just shouldn't have let them continue dropping eggs between the panels after the panels had maxed out, it would've probably be much more manageable (well, I'll know that in a minute... reducing the nubmer of bugs to just enough to keep the solar going at full power).
  5. Uuuh, feels straaange to find myself and Brothgar in the same sentence, even if it is his build I am using. Not a big fan of his heavily modded playstyle, but to each his own (and absolutely hats down to all of his contributions and calculations). Yea, but "regular" gameplay can differ quite a bit from person to person... I tend to be a fairly slow and occasionally too-careful player (which unfortunately meant that the map where I've finally reached end game got rudely messed up by the Launch upgrade around cycle 1500 after pouring at least a year into it...). Which for somehow resulted in me constructing the shine bug solar first, integrated mini industry+oxygen brick second, and plumbed toilets after either of those in my current playthrough (I wanted a way to destroy of my germy P-water rather than designating a temporary dumping ground and since I usually do that by sending it to the electrolysers... we got metal refinement before proper loos). The thing is, this is a game where people like to come up with over-the-top and limit-pushing contraptions and systems all the time. But I can get your point that optimising for 800+ critters on the map should probably not be a priority (and I made a bit of a mistake estimating how many shine bugs I have trapped in there... just continued adding bugs even after reaching max light, for... lime and lazyness I guess. So I do now, in fact, have 700+ domesticated critters. But, considering that I don't really need that many to keep my power going, I guess it's lights out for most of them so my hatches can get ranched). Now, this, on the other hand, I can fully sign. I might have a hunch that there could be something done to improve the handling/decrease the load of critters trapped in a single tile. But, as somebody with training in computer programming, I don't even want to begin imagining the complexity of a simulation with this many interacting parts and systems. On some very, very, specific occasions I might be fairly sure I know what's causing the problem (like, when trying to store all the salt water on Oceania in a single infini-storage, and the game suddenly reading -2,147,483,647kg/tile before crashing), but in case of 800+ critters on a map... I wouldn't even dare to guesstimate.
  6. I agree with most of what you said. I actually really love ranching-based economies, and in my current playthrough am trying the shine bug solar power. They're all trapped in one tile, I think the total count is still well below your 600 slicksters (I would say maybe ~100 bugs atm) and it takes my rancher forever to summon any critter in any rach to the grooming station.
  7. Seems like my very late game base crashes frequently on save after update. About every 2-3 cycles, the whole game will just crash when attempting to save. Now, granted, it is a very late game base and the logs are reporting an out of memory error, but it seems like the crashes were nowhere near as frequent before the update. Also, I haven't been adding any more complexity to the base since the update, if anything I've been mining out the whole map and making neater ladders for better pathfinding. Anything to do except get a better computer? Log and savefile attached. The Salted Olive Orchard.sav
  8. Still happening... Currently 11 molten slicksters starving in a room at ~2000kg/tile CO2.
  9. I found my log files this time, following the instructions you posted. However, when posting a new bug, the instructions under the post for "For instructions on how to get your logs, click below" are not correct and actually instruct to look for the file elsewhere. I'm guessing that's where the confusion about the log files comes from
  10. Playing completely and utterly unmodded. My best guess is that they have some minimum "delay" between two feeding intervals (and there is definetely a time it takes then to "digest" CO2 and turn it to petrol, and after they feed they will not feed again until they expel their waste). I think this is what delays them from coming to the grooming station sometimes when the rancher is calling them. But also, reversely, if they start getting groomed, they will not feed again until the grooming is finished... and since there's a minimum delay between two feeding instances, once the grooming delays their feeding schedule, they never catch up again.
  11. Is there a problem with logfiles? I can't seem to find mine either
  12. I think there is something wrong with the Molten Slickster eating frequency or calorie consumption when tame (maybe in combination with the grooming buff duration or interruptions to "feeding" frequency caused by grooming - it seems like they will postpone "feeding" while being groomed). As Slicksters reach their middle and then old age (~70+ cycles), they start "starving" in a room full of CO2 (2kg/tile pressure with a constant supply) at a comfortable temperature (currently 112*C). The reason I say "starving" is that they don't die: they seem to lose just a tiny bit more calories between two "feeding" instances than they gain when "feeding". From an early age, they are constantly "hungry". When they hit middle age (~70 cycles), their calorie counter hits zero, and I get a starvation warning, lasting only for a second, as they "feed" immediately afterwards. From this age onwards, I get constant tiny "critter starvation" blips, as they deplete all their calories every time before "feeding" more. It only lasts for a moment, and I have not measured the extent of the effect on their reproduction rate, but this effectively lowers their reproduction speed due to their reproduction rate dropping to 2% with the "starving" debuff (which makes them "glum"). Constant popping and dissapearing warnings are also somewhat distracting. Not sure if there is an effect on the CO2 consumed per cycle. Also not sure if regular Slicksters have the same problem, as I've only ranched the Molten ones. Finally, try as I might following the instructions below, I could not find the log file anywhere. In fact, I hit "search" through the entire ONI folder in SteamApps as well as the whole ONI folder in \Documents\Klei, and the file called "ouput_log.txt" (or anything containing "log" or "output" for that matter) simply does not exist. Noticed it first two days ago (with the hotfix/update?), then yesterday it seemed like it got better (but maybe all of the old starving slicksters just died off?) and today it's happening again. Slickster Criter Starve.sav
  13. Ah, yes, no bug. Good code is always written so that if the users reach the hard limit, the program or service crashes to teach them a lesson. Totally intended behaviour. In fact, somebody else reported a game crash due to the same problem: Since there is clearly nothing to get fixed here and the devs consider this an exploit to be punished, when the devs responded to the post they laughed at the OP there, told him that his world was lost, told him off for designing a system like that in the first place and that there's no need to change anything. Oh wait, no, actually, the devs were interested in what made the game crash, looked into his logs and savefiles, and then suggested what to do to be able to continue playing and using that system while they're looking into that behaviour. There will always be people pushing on the limits of what games (especially sandbox games like this) allow them to do. If something is not an allowed mechanic, it should not be in the game, rather than crashing it, I think.
  14. Seems like I made the same bug report a few days later, just noticed this reports the same situation (except I never enabled debug but thankfully managed to reroll far enough back through autosave) Is this something you will eventually be working on, or is it unintended gameplay and we need to focus on designing different systems? There seems to be a very divided opinion of this...