Jump to content

Hatch Ranch Mark 3: Fully Automated Min-Maxed


Recommended Posts

Hello there. Some of you might be familiar with my previous hatch ranch design but I'm happy to say that through collaboration with the community on the discord I've come up with a much more efficient hatch ranch.

The original design kept track of the population of a 96 tile ranch and sustained it at 8 and was fully automated. If a breeding hatch died, it would pull the next egg out and put the egg in an area at the top of the ranch. Once the egg hatched, the critter would be pushed down into the ranch to replace the dead breeder.

The main issue with this old design is that you had to factor in the lifespan of the hatch as being 120 cycles, since you waited the full 20 cycles for the egg to hatch before the breeder was replaced. You would get 533 calories per cycle for each hatch when making barbeque.

The new design makes use of some other mechanics to replace a dead breeder much sooner without having to wait the full 20 cycles for a fresh egg to hatch. In this way you can instead calculate your calories using the lifespan of 100 cycles for the hatch at 640 daily calories per hatch. The improvement could be as much as 107 calories every cycle per hatch, a very substantial increase. The best part is that it still requires absolutely 0 babysitting and is fully automated. Here's links to the images and then I'll get into more detail:

Overview
Conveyor Overview
Automation
Close Up of the top

All eggs are picked up and sent to the little puddle of water in the room at the top of the ranch. When all 8 breeders are alive, the mechanized airlock above the water puddle is closed. This creates surface tension with the puddle of water, causing it to fill the entire block. In this way even a tiny drop of water can drown a hatch. The sweeper is able to reach through the pneumatic door to remove egg shells and meat.

If a breeder dies and the population falls below 8, the mechanized door above the puddle will be open. This allows the puddle of water to fall flat and will not drown any hatches. The dropping mechanism to the right of the puddle of water are two pneumatic doors. 

If the critter walks into the pneumatic door and it closes, it will fall down into the ranch. So, I've set up some automation to do this four times every day. There are four cycle sensors each set to open for 1% of the day. The first one opens at the start of the day, the second at 1/4 in, the third at 1/2 in, and the fourth at 3/4 through the day.

The doors are set to an AND gate so the doors only cycle if the population in the ranch is below 8 AND one of the cycle sensors has triggered. 

That's the main part of this build. Down below you just have the usual conveyor lines. The leftmost loader pushes the eggs up to the puddle room. The middle loader removes coal and the rightmost loader removes eggs for critter breeds you don't want to a drown pool elsewhere (sage hatch eggs in this instance). You can replace the rightmost loader with an element sensor and conveyor shutoff if you wish.

I've also put a failsafe automated notifier in each ranch that will pause the game and issue an alert if the population should ever get above 8 somehow. That will alert you to fix the issue and resume egg production ASAP. Filter gate set to 30 seconds prevents it from triggering when eggs are traveling upward.

Now if this design is imperfect in some way please let me know. But I've tested it and everything seems to be gravy so far. Thanks guys! Crossposting on reddit btw.

Link to comment
Share on other sites

Hey bud, I was a fan of the last build - I've tinkered and used it ever since.

The changes to chutes being automated and opened/closed simplified my build a lot (no shutoffs needed) - however I still opt for a central egg dumping/sorting/drowning area as I feel it's cleaner. For the dropper doors I just use a timer on default settings 10/10 and it works beautifully :D 


image.thumb.png.b3e061d7ee03f98bded031dfabf921c6.png
 

The only downside I can see with your build is the initial setup, the part where your eggs aren't naturally staggered - theres a *chance* multiple eggs could hatch at the same time and drop multiples - but other than that it seems clean :) 

Link to comment
Share on other sites

Quote

I still opt for a central egg dumping/sorting/drowning area as I feel it's cleaner.

Yes it will be cleaner with just one and someone on the discord suggested that the top part of my design might be merged with the pez design so you would only need one. The pez design makes more use of the dead space but it also increases travel time for the rancher which might be a big negative for some. Here's that one: 

 

Quote

The only downside I can see with your build is the initial setup, the part where your eggs aren't naturally staggered - theres a *chance* multiple eggs could hatch at the same time and drop multiples

Yeah that for sure might happen but the automated notifier will catch that for you. Then you can murder one of the doubles and things should sort themselves out from there. 

Thanks for the feedback

Link to comment
Share on other sites

How about using water to force hatch movement as well? You could also make an "on-deck circle" to further reduce the breeder replacement wait time. Something like this perhaps.

image.thumb.png.f6ad9bffb2d3a9d59c46fc2e452ae907.png

image.thumb.png.c94c71c368b06cea98384f603ce6aa23.png

Babies will drown at the chute unless the door is open due to no on-deck hatch. With the door open, babies will immediately move to the safe on-deck circle underneath the mesh tile. Second door is locked unless the ranch needs another breeder. With water levels at 350kg, a waiting adult hatch will quickly jump into the ranch when the door opens. Hatches will not path back into the water. Middle sweeper collects meat and shell from the chute, sweepers in the ranches can do everything else. Add loaders/receptacles as desired. Might have to get sweeper access to the on-deck circle, don't remember what the starvation times of a tamed glum hatch are.

Link to comment
Share on other sites

Hello there thanks for the comments.This is an interesting idea. I checked it in sandbox and everything seems to be in order. There are a couple of concerns I have though. First, I can think of cases where a replacement hatch might be kept in the holding square long enough to starve. Then the meat has to be manually removed.

Second, the sizing is a bit awkward as this ends up being 29 tiles wide for four ranches which is what I usually need. An odd numbered module size is... difficult for those of us with obsessive tendencies :D

However, I can see if I built the core of my base at 29 tiles wide at the start then it would fit perfect. I will definitely try this in my next base as it actually looks a little bit nicer than what I have going on. The cost in water is a little higher but the cost in metal is much lower.

Having an adult hatch ready to go as a replacement may increase the effective calories you get out of the ranch since you may prevent time spent a "tiny baby" in the breeding room. On the other hand, if the replacement hatch ends up being much older before it gets into the breeding room, you'll end up having more time on average spent in the end of life stage where the hatch cannot produce any more eggs before dying.

With this in mind, those two effects might cancel each other out and make it a wash. I still like the look of this though and will try it out. Nice design!

Link to comment
Share on other sites

10 hours ago, Satyrical364 said:

On the other hand, if the replacement hatch ends up being much older before it gets into the breeding room, you'll end up having more time on average spent in the end of life stage where the hatch cannot produce any more eggs before dying

That's an interesting thought I hadn't considered. Deserves some in depth analysis and math. My gut reaction is, as you say, that there probably isn't a big difference either way. The big improvement is in not having to wait 20 cycles for a fresh egg to hatch.

Regarding the starvation issue, did a bit of testing to refresh my memory on the numbers. Hatches are born with 6,300 kcalories and consume 700 a day. However a glum baby has a total of -98% metabolism so they reach adulthood with ~6,230 kcalories. Glum adults have -80% metabolism and should reach about age 50 before starving. Once breeder ages get spread out a bit, that seems plenty of time for a breeder to die and need a replacement. Manual removal would be needed if you load up the ranch with close aged hatches at the start, but that ought to only be an issue when starting the ranch.

I usually don't do critters, but I'll probably give this design a shot next time I get into a playthrough just to see how well it does over several hundred cycles.

 

My debug/sandbox test in progress for any interested: Hands Off Hatch Ranch.sav

Link to comment
Share on other sites

2 hours ago, wachunga said:

The big improvement is in not having to wait 20 cycles for a fresh egg to hatch.

This is the part I don't really follow here, whats the issue with waiting for the eggs to hatch? Doesn't cost you anything in terms of dupe time/resources, all it means is that your stables occasionally run at 7 critters periodically instead of 8.

Easiest solution would be to just build an additional stable for a buffer if you're minmaxing your coal/meat supply to the kilo. Let's face it, all these designs we come out with are generally modular so it's a 2 minute job to copy/paste the layout and slap down an additional ranch.

I genuinely can't make it more straight forward than 1 x critter sensor and 1 x timer (which works perfectly) so i'm struggling to see what benefit you gain here except for opening up a new can of worms when it comes to critter pathing in a late game base. Need I remind you of how "dopey" dupes/critters get late game... The ponder lag is real ;) We regularly observe "frozen" critters, in a state of permanent lockdown...

 

Link to comment
Share on other sites

15 hours ago, wachunga said:

That's an interesting thought I hadn't considered. Deserves some in depth analysis and math. 

Let me try the math. I've recently been told by multiple people that the base reproduction rate of hatches is actually 1.66%, and not 2% as the game tooltip indicates. This means they reproduce at a rate of 16.66% per cycle, so a hatch will lay an egg every 6.02 cycles when tame and well cared for. The productive lifespan is 95 cycles so we can expect the hatch to lay 15.78 eggs over its lifetime. Rounding down, this means it lays 15 eggs.

The 0.78 progress toward an egg is wasted and makes an end of life, non productive life of the hatch. We can calculate how many cycles this will be by calculating what 78% of 6.02 cycles is. That's 4.7 cycles of non-productive time per hatch if it starts reproduction at age 5 and is perfectly cared for.

However, the math changes depending on when the hatch gets groomed and starts reproduction, that remaining fraction of an egg could be literally anything from 0.01 to 0.99 of an egg.

We must also consider that in most instances your design will be eliminating the 5 cycles of the baby hatch. So, in order for your design to come out less efficient than mine, which always includes 5 cycles as a baby and often a bit of egg time, the wasted reproduction at end of life would have to be darn near to the maximum of 99% of an egg. I think your design would come out ahead given this.

 

12 hours ago, Lifegrow said:

This is the part I don't really follow here, whats the issue with waiting for the eggs to hatch? Doesn't cost you anything in terms of dupe time/resources, all it means is that your stables occasionally run at 7 critters periodically instead of 8.

If I understand you right, you're basically saying why we should have an adult hatch waiting in replacement queue beneath each stable, being non-productive, when we can just run an additional stable to make the extra calories.

To think of it this way, if you run 4 stables and they occasionally are stuck at 7 of 8, you could make up for the slack with a fifth stable at 3-4 population. 

However, a design like Wachunga's has several advantages. First, you take some hits to travel time the more stables you have. It becomes worse the farther apart the grooming stations are from each-other because the rancher will end up running back and forth from the stations.

Second, it takes more map space to make additional stables. This isn't a concern in late game and not even a concern on some asteroid types. However, high heat asteroids or magma channel modifiers make the biggest issue with an expansionist philosophy so these more compact solutions would be more useful there. From talking with other ONI fans I've come to realize that compact designs that do more with less are very important to many people despite the huge size of the maps. A lot of the players just really desire and strive for this. I've even talked with some players that are willing to use a LESS efficient design just because it is more compact. Something about aesthetics I guess.

Third and fourth, each additional stable carries a material cost and power overhead if you use shipping. In other words, if your stables are more kcal efficient then you also save power and materials.

I think as with many things in ONI it comes down to style and a desire for optimization. Let's face it, the game is easy enough once you learn it that you can do whatever you want and it won't matter. However, I have an obsessive personality so I will continue to look for sleeker, more elegant solutions even if it boils down to splitting hairs in the end :D

 

12 hours ago, Lifegrow said:

Need I remind you of how "dopey" dupes/critters get late game... The ponder lag is real ;) We regularly observe "frozen" critters, in a state of permanent lockdown...

Wow I've never seen a frozen critter but I generally don't play a map much beyond 300 cycles or so. Also I don't build nearly as many different machines and modules as I've seen in your bases. However, this wouldn't be a reason not to go with a design like Wachunga's or mine since the design you are currently using already relies on hatch movement to use the dropper. 

Either way the hatch has to move to the place where it can be either dropped into the stable or can jump up into it. 

Link to comment
Share on other sites

3 hours ago, Satyrical364 said:

If I understand you right, you're basically saying why we should have an adult hatch waiting in replacement queue beneath each stable, being non-productive, when we can just run an additional stable to make the extra calories.

Not really, what I was saying (and was maybe badly worded) is that unless you're monitoring your coal production/meat supply to the exact required amounts, it really doesn't matter all that much if you occasionally aren't running with 8 mature critters.

If you were to run a base whereby you needed the exact amount of resources, i'd still advise a buffer of an additional stable for additional coal (i.e. ceramic/refined carbon manufacturing) or additional meat (rotting/dropped/stem cells/whatever). At which point it's irrelevant.

3 hours ago, Satyrical364 said:

First, you take some hits to travel time the more stables you have. It becomes worse the farther apart the grooming stations are from each-other because the rancher will end up running back and forth from the stations.

You and I both know the biggest hit to ranching time isn't dupe travel time, but critter reaction/travel time. A very visual and painful example being the drecko. 

3 hours ago, Satyrical364 said:

Second, it takes more map space to make additional stables. This isn't a concern in late game and not even a concern on some asteroid types. However, high heat asteroids or magma channel modifiers make the biggest issue with an expansionist philosophy so these more compact solutions would be more useful there. From talking with other ONI fans I've come to realize that compact designs that do more with less are very important to many people despite the huge size of the maps.

This confuses me - your build is 36 tiles larger than a standard full size hatch ranch, due entirely to the fact you manage the population outside of the stable. Makes no sense to me. If you're talking compact, you can't get smaller than the build I've already explained above. Mines 5 tiles larger.

3 hours ago, Satyrical364 said:

Third and fourth, each additional stable carries a material cost and power overhead if you use shipping. In other words, if your stables are more kcal efficient then you also save power and materials.

This isn't entirely true - or rather it's only partly true. Yes - if you build 20 loaders in each ranch it would cost you more metal - but in terms of power, it would be the exact same usage.

In terms of materials - Loaders/sweepers aren't expensive, neither are conveyor rails. Regardless, your build costs more in materials than any i've seen, again due to the fact that each stable requires an additional loader/sweeper for population management. You could achieve the exact same with some automation wire and an element sensor connected to a chute.

In terms of power - Loaders/sweepers only consume power when they're active. Doesn't matter if you have 1 or 100, it'd use the same amount of power to move the same resources.

I'm really not trying to take your build apart bud, you should know my mindset/manner from stream - i'm just confused by what you've offered here based on your reasons for offering it (if that makes sense?). If your focus is cost in terms of space/power/materials - you've missed the mark entirely. The kcal min/maxing is something that really doesn't interest me, so i'm probably not the best to discuss that with. Historically @wachunga was never a fan of tinkering with critter builds - I suspect like me he hates the fact that debug refining them is a pain in the backside due to hatching times/maturity etc. I'm sure if he's got the bug though he'll be a worthy ally for you to figure this out ;) 

3 hours ago, Satyrical364 said:

Wow I've never seen a frozen critter but I generally don't play a map much beyond 300 cycles or so. Also I don't build nearly as many different machines and modules as I've seen in your bases. However, this wouldn't be a reason not to go with a design like Wachunga's or mine since the design you are currently using already relies on hatch movement to use the dropper. 

With you only playing to cycle 300ish, maybe you don't experience this all that much - play to cycle 800+ then see how you feel. Play to cycle 1200+ and then come buy me a beer ;) I'm not saying that yours or wachungas builds aren't perfect by the way, I understand that it saves ~5 cycles per critter in terms of maturity but as stated above unless you're minmaxing your coal/food it really is a non-issue to begin with. 

4 hours ago, Satyrical364 said:

Either way the hatch has to move to the place where it can be either dropped into the stable or can jump up into it. 

I agree, but I think you can do it much easier.

Link to comment
Share on other sites

So critter sensors are super buggy on load. In a full ranch of 8, the sensor first reads 0, then 11, then 2, and finally 8. This can screw up any build using a critter sensor. Add a filter and/or buffer as appropriate to prevent transient signals doing something dumb. Practice safe ranching kids.

No other issues discovered as of this time, testing continues.

Link to comment
Share on other sites

5 hours ago, Lifegrow said:

Not really, what I was saying (and was maybe badly worded) is that unless you're monitoring your coal production/meat supply to the exact required amounts, it really doesn't matter all that much if you occasionally aren't running with 8 mature critters.

If you were to run a base whereby you needed the exact amount of resources, i'd still advise a buffer of an additional stable for additional coal (i.e. ceramic/refined carbon manufacturing) or additional meat (rotting/dropped/stem cells/whatever). At which point it's irrelevant.

Oh sorry about that. I can understand that and I typically do run an additional stable over what I need just so I can take on new dupes whenever I want to without worrying about calorie deficits. With wachunga's design, as I see to be superior to the one I initially laid out, however, I'll need less stables overall and that is primally satisfying for me. 

 

6 hours ago, Lifegrow said:

You and I both know the biggest hit to ranching time isn't dupe travel time, but critter reaction/travel time. A very visual and painful example being the drecko. 

Sure, and travel time can be mitigated by skill ups and better tiles, ladders, tubes, etc. while critters always move the same speed. However, you asked what benefits these other builds offered and I listed everything I could think of. Critter movement may be a bigger deal but duplicant travel time is still a deal.

6 hours ago, Lifegrow said:

In terms of power - Loaders/sweepers only consume power when they're active. Doesn't matter if you have 1 or 100, it'd use the same amount of power to move the same resources.

I take your point, my thinking was off on that.

6 hours ago, Lifegrow said:

In terms of materials - Loaders/sweepers aren't expensive, neither are conveyor rails. Regardless, your build costs more in materials than any i've seen, again due to the fact that each stable requires an additional loader/sweeper for population management. You could achieve the exact same with some automation wire and an element sensor connected to a chute.

Yes this is true.

6 hours ago, Lifegrow said:

I'm really not trying to take your build apart bud, you should know my mindset/manner from stream - i'm just confused by what you've offered here based on your reasons for offering it (if that makes sense?). If your focus is cost in terms of space/power/materials - you've missed the mark entirely. The kcal min/maxing is something that really doesn't interest me, so i'm probably not the best to discuss that with.

No the focus is not reducing power or materials, I had thought there may be some benefit in those regards but you've convinced me otherwise. The real impetus for the design was kcal efficiency per hatch and thereby a reduction in the number of stables required. The old design and the one you use currently works fine and is also very neat, but I feel this to be an evolution (particularly Wachunga's innovation).

Above all I made it for me because I honestly hate building stables and am always on the lookout for any way I can find to make less stables, especially considering I restart after a few hundred cycles and end up building way more stables for that reason. I believe hatch ranching to be the most stable (pun not intended) start to every game, though, so even though I hate the building I love the results afterward.

If you don't share my sentiments then I can understand how the design in my OP would raise question marks. However, I'm sure there's others like me who might enjoy an increase in efficiency.

5 hours ago, wachunga said:

So critter sensors are super buggy on load. In a full ranch of 8, the sensor first reads 0, then 11, then 2, and finally 8. This can screw up any build using a critter sensor. Add a filter and/or buffer as appropriate to prevent transient signals doing something dumb. Practice safe ranching kids.

I never noticed that but I don't doubt you. A filter gate would probably be my choice, I use them already for all of my automated notifiers because of similar issues on loadup.

Link to comment
Share on other sites

8 hours ago, Satyrical364 said:

Above all I made it for me because I honestly hate building stables and am always on the lookout for any way I can find to make less stables, especially considering I restart after a few hundred cycles and end up building way more stables for that reason. I believe hatch ranching to be the most stable (pun not intended) start to every game, though, so even though I hate the building I love the results afterward.

Hah, I share your feelings on this one, I always groan at the concept of "Alright, I suppose we do actually need to start ranching now!" but the rewards are always invaluable.

Again, just to be clear - In no way was I trying to tear your build apart, I was genuinely looking for understanding. Efficiency is always something that people strive for around here so I very much get where you're coming from. My focus is normally to strive for efficiency only in the areas with the biggest payoffs, i.e. material handling, dupe logistics, etc as I personally do play every colony well into the 1000cycles mark. Knowing that the end of the colony is inevitably being caused by poor game optimisation and is inescapable makes me cherry pick where I focus my efforts.

It might be insightful for you to try a ~1500 cycle playthrough so that you can see how some of these builds behave in the late game though, it might shock you how things start coming apart at the seams, it may also give some insight in to why some people handle game mechanics the way they do. I only wish the Klei devs would do the same ;) 

Link to comment
Share on other sites

4 hours ago, Lifegrow said:

It might be insightful for you to try a ~1500 cycle playthrough so that you can see how some of these builds behave in the late game though, it might shock you how things start coming apart at the seams, it may also give some insight in to why some people handle game mechanics the way they do.

I think I did 500 cycles once but anything beyond that is not realistic for me because I just don't enjoy late game at all. If you could see my enjoyment of the game on a graph as the cycles progress there would be a sharp nosedive until I just stop playing.

I've actually attempted to make past this emotional wall by only allowing myself to play the late game colony, and in practice I just end up playing the game less and less until I move on to other games. This is my own hangup but someday perhaps I'll get past it.

Link to comment
Share on other sites

I'm with Lifegrow here. I think opinions are heavily influenced by playstyle, for sure mine is.

On 8/17/2020 at 7:49 AM, Satyrical364 said:

The real impetus for the design was kcal efficiency per hatch and thereby a reduction in the number of stables required.

I totally get it.

But you are also in full control of the number of dups you hire. So a more efficient stable design may reduce the number of stables required only if you consider the number of dups as a constant. And only at the right watermark.

For me, at least, it's the other way around. I control the number of dups and what a better design means is only that I could hire one dup more w/o building more stables. So I don't do that. With a less efficient design it's not one stable more, it's one dup less.

I decide when it's time to keep the population constant, or when it's time to expand. When it's time for expansion, I start building new stables right away. Filling the new stables with critters means less meat for dups, on the short term, that's why having some extra food is always a good idea. Stable efficiency doesn't change when I build the stables, if I'm expanding. It's at the beginning of the expansion phase.

When it's time to keep the population constant, that's when efficiency comes into play. It may affect how many dups I hire. But does it really? I usually stop at 4 stables, 16 dups. At least for early game (or early-mid game). I use a design which is basicly Francis John's. Stables with 8 critters, eggs removal, evolution chamber, 8 unpowered incubators (well, manually powered, I have an automation switch I can use to speed things up).

My (conservative) formula is 7:4, so I know I could sustain 18 (and most likely 19) dups with 4 stables. I still like to stop at 16. Would it make any difference knowing that I could go to 20 instead of 19, with a more efficient design? No, not really.

I like to overproduce food, for the reasons stated above, and I like the idea that I could hire a dup if one that is very good appears at the pod.

But I know that if I keep hiring good dups, one day I'll find I need another stable... be it at 19 or 20 really doesn't matter much. The only case in which it matters is if you've decided on 20 dups and it's a hard choice, and you really can't live with just 19. So using a setup that is more advanced than mine allows you to have 20 instead of building more stables, which is what I'd have to do... unless...

Aiming at the decimal point in calories makes sense if that's really your only source of food. What about dreckos? Do you ranch those too? I do. They are a poor source of food compared to hatches, and I have only one breeder ranch and I really don't bother if it's full or not. That's probably only 2 dups worth of food, but it's still enough to throw off precise calculations. I also keep a small pool next to the pod where wild pacus end up. They are zero maintainance food, not much, but again enough to make a difference on how many dups my colony can support food-wise at any given moment.

Even the wild critters that roam the map randomly provide some food. And wild plants.

So, I could probably have 20 dups, too, w/o building an extra stable or changing the design of the existing ones. Maybe even 22. Sure, you say, you still have one extra dup, but I wonder do you know precisely how many dups you can sustain, all factors included? if not, you have to play conservatively too.

I'm not sure if I'm managing to have my point come through, but why bother with an optimization whose effects are likely to be overshadowed by other random factors? (well not completely random, let's say harder to measure with the same level of precision) it's kinda going to be lost in the noise.

You have to isolate it to notice... you have to play at the precise edge of the max population for a very long time and factor out any other external source of food. Then yes you can see the difference.

Of course you can reply "because I like it". It's a perfectly acceptable answer to me.

But it's not because you can build less stables, that's very situational, you really have to try hard and create the right conditions for that to happen.

E.g. in my typical colony, you'd have to challenge me to:

- have 4 stables - 5 is totally unacceptable;

- have 20 dups - 19 is totally unacceptable;

- not ever power any incubator; not once;

- ranch no other critter (no plastic from dreckos, ecc);

- not accept food or critters or eggs care packages from the pod;

- not collect meat/fillet/fruits produced by wild critters and plants;

- survive 100 cycles or:

- destroy all the extra food I have produced to get both my dup and my critter population up to those level (20/32), and survive 10 cycles.


Then yes, if I can't break any of those rule, I'll have to switch to a more advanced stable design than FJ's or build an extra stable.

And that's not how I play. I don't prevent dups from collecting random food, I ranch other critters for other purposes, I keep the food I've overproduced in the past, and most importantly, I never play with a number of dups I can sustain, food wise, but only barely.

I think most players to the same. So for me FJ's design for stables is good enough and I woundn't notice the difference with a more efficient design because those factors have much a larger impact on my colony ability to survive (food-wise, of course).

 

Link to comment
Share on other sites

On 8/15/2020 at 8:13 PM, wachunga said:

How about using water to force hatch movement as well? You could also make an "on-deck circle" to further reduce the breeder replacement wait time. Something like this perhaps.

image.thumb.png.f6ad9bffb2d3a9d59c46fc2e452ae907.png

image.thumb.png.c94c71c368b06cea98384f603ce6aa23.png

Babies will drown at the chute unless the door is open due to no on-deck hatch. With the door open, babies will immediately move to the safe on-deck circle underneath the mesh tile. Second door is locked unless the ranch needs another breeder. With water levels at 350kg, a waiting adult hatch will quickly jump into the ranch when the door opens. Hatches will not path back into the water. Middle sweeper collects meat and shell from the chute, sweepers in the ranches can do everything else. Add loaders/receptacles as desired. Might have to get sweeper access to the on-deck circle, don't remember what the starvation times of a tamed glum hatch are.

 

Great build, but you need to add a sensor to weed out garbage eggs (unnecessary breeds) and drown them elsewhere.

Link to comment
Share on other sites

1 hour ago, TheMule said:

My (conservative) formula is 7:4, so I know I could sustain 18 (and most likely 19) dups with 4 stables. I still like to stop at 16. Would it make any difference knowing that I could go to 20 instead of 19, with a more efficient design? No, not really.

Hello there and thanks for stopping by. For me the calculation is different because I play on ravenous hunger. On my difficulty, those four stables are only going to feed 8 dupes in your example, it isn't as easy to build up huge stocks of extra food (2x as hard in fact), and since you need 2x the number of hatches to feed everyone, you also need 2x the amount of grooming labor. An extra 100 calories per cycle per hatch in your example would come out to 3,200 extra calories per cycle for the four stables, almost enough to feed two extra dupes. 

The grooming labor becomes a big bottleneck. I have 5 stables of Hatch and one for Drecko. After a while I notice that one of my dupes was pretty much exclusively doing ranching tasks, so I had to make another rancher. That's a lot of labor spent.

If you go with Wachunga's design, you can get the extra 100 calories per hatch per day and it costs less materials than Francis John's design you mentioned.

Much of your post seems to be stating "Why should I choose a more efficient design when I don't need it?" 

And I would reply "Why would you choose a less efficient, more complicated design?"

If I've understood you correctly, your answer is that you just don't want to and you like how you do it already. That's fine. A lot of people like their ways of doing things and I certainly have nothing to gain in trying to convince you. 

2 hours ago, TheMule said:

Stable efficiency doesn't change when I build the stables, if I'm expanding. It's at the beginning of the expansion phase.

Well it certainly does for me. Higher efficiency means I need less hatches to reach sustainability and therefore I can get to sustainable barbeque earlier. The less efficient, the more hatches you need and the longer the delay to a barbeque diet. I also crunch the numbers before adding a new dupe and I will not add one without enough food production already in place to sustain them, unless I happen to have an obscene food surplus. I'll admit this generally isn't necessary, but it makes me feel more secure.

Link to comment
Share on other sites

On 8/16/2020 at 7:20 AM, wachunga said:

That's an interesting thought I hadn't considered. Deserves some in depth analysis and math. My gut reaction is, as you say, that there probably isn't a big difference either way. The big improvement is in not having to wait 20 cycles for a fresh egg to hatch.

Regarding the starvation issue, did a bit of testing to refresh my memory on the numbers. Hatches are born with 6,300 kcalories and consume 700 a day. However a glum baby has a total of -98% metabolism so they reach adulthood with ~6,230 kcalories. Glum adults have -80% metabolism and should reach about age 50 before starving. Once breeder ages get spread out a bit, that seems plenty of time for a breeder to die and need a replacement. Manual removal would be needed if you load up the ranch with close aged hatches at the start, but that ought to only be an issue when starting the ranch.

I usually don't do critters, but I'll probably give this design a shot next time I get into a playthrough just to see how well it does over several hundred cycles.

 

My debug/sandbox test in progress for any interested: Hands Off Hatch Ranch.sav

 

I worked on the scheme, now there is egg filtration and clearer door operation

Kutuluk_HandsOffHatchRanch.sav

h1.jpg

h2.jpg

h3.jpg

Link to comment
Share on other sites

2 hours ago, Satyrical364 said:

Hello there and thanks for stopping by

Hi! Thank you for sharing your build and starting this interesting conversation.

2 hours ago, Satyrical364 said:

For me the calculation is different because I play on ravenous hunger. On my difficulty, those four stables are only going to feed 8 dupes in your example

Yes. You just have to halve the number of dups but the reasoning is the same.

2 hours ago, Satyrical364 said:

An extra 100 calories per cycle per hatch in your example would come out to 3,200 extra calories per cycle for the four stables, almost enough to feed two extra dupes.

I'm not sure that figure is right. It's 0.5 dups to me. More on that later.

2 hours ago, Satyrical364 said:

it costs less materials than Francis John's design you mentioned

 

2 hours ago, Satyrical364 said:

Why would you choose a less efficient, more complicated design?"

I'm not sure about the materials. I won't even go there, any difference if present is negligible.

BTW, I've never made any argument against  @wachunga's design. I find it beautifully clever.

But does this seem more complicated to you? really?

image.thumb.png.f686a8dbe3d4a4b4142b3104c22e8143.png

I'm sorry but I can't agree on that. I don't even need to show you the automation layer because it's empty, not a single automation wire. This is way simpler in my book, both to build, and to operate. Expecially to build.

The question is "why would I use a beautiful, efficient, complicated build over a much simpler one, other than because I like the former more?". It is more efficient, but by such a small margin that it doesn't change my game at all, it's barely noticeable.

2 hours ago, Satyrical364 said:

If I've understood you correctly, your answer is that you just don't want to and you like how you do it already.

On the contrary, based on what I like, I like @wachunga's design more. It's just that it's more complicated, and it happens in a phase of the game when I tend to favor cheap and easy over optimized and expensive, expecially in build time.

But everything revolves around that 100kcal/cycle/hatches. If I'm right (and I'm saying if), the way I do things, 4 stables support 9 raveous dups. 9.5 pushing it. The way you do it, they support 9.5, pushing it 10. [Edit: I wrote this before doing the math below, based only on the rules of the thumb I use. It turns out, I wasn't off much]
My point is that I'd build my 5th stable pretty much at the same time you would. We get the 9th dup then we both start building the 5th stable.

If you're right, my stables support only 7 dups. That would be 14 regular dups, or a ratio 32:14, that is more that 2 hatches per regular dup. That's not right. I use 1.75 and I know I'm being conservative. 

Well, I didn't mean to, but let's venture into some math...

A single hatch produces 15 eggs in 100 cycle. Or actually, an adult hatch produces 15 eggs in 95c.

Having 8 incubators means that on average, one egg hatches every 2.5c. Add 5 cycles to become an adult, and it's like a adult hatch had a 102.5c lifetime, for the same 15 eggs.
But that doesn't account for the time a baby sits in a incubator waiting for a place in a stable, which increases the chance of an immediate replacement and when it gets moved to a hatch, it's already older than 0, so you loose less than 5 cycles. Hard to compute the accurate loss of efficiency, but it's about 101.5 or 102 cycles per 15 eggs. 

 

15 eggs = 15 BBQ = 60,000 kcal in 95 cycles in theory, with perfect adult replacement. It's 1.5833 hatches per (standard) dup.  4 stables, 32 hatches, 32/1.5833 = 20.2 standard dups, 10.1 ravenous. At best, for the perfect build. And I'm willing to admit that @wachunga's can get very close.

The same 60,000 kcal in 102c is 1.7 hatches per dup. So 32/1.7 = 18.82 standard dups, 9.4 ravenous.

And that's it. When I, with my 4 simpler stables, hire my 9th dup, I start thinking about the 5th stable. I'm overproducing for almost 1/2 dup, meaning also that hiring my 10th places me half a dup worth negative. Yes, you are in slightly better position, maybe with @wachunga's build you are a bit more confident in hiring your 10th dup, since you can trust your 4 stables either be able to or come very close to support 10 dups. But we're talking 0.5 dups here. All other factors equal, we would build the 5th stable at almost the same time.

And that's not counting, as I wrote in my previous post, other all other sources of food you can't really control or measure accurately. They can add anywhere from 0 to 2 extra ravenous dups. What I mean is that the figures above become:
10.4 +/- 1 for me and 11.1 +/- 1 for you. The difference is within the error. Which is a mathematical way to convey the same idea I was trying to explain before. 
 

You should totally use @wachunga's build if you like it. And I probably will too, if I have the opportunity, it's simply brilliant. But I'll probably still build my 5th stable after I hire my 9th dup (if I'm playing with ravenous settings).


 

 

 

Link to comment
Share on other sites

26 minutes ago, TheMule said:

The question is "why would I use a beautiful, efficient, complicated build over a much simpler one, other than because I like the former more?". It is more efficient, but by such a small margin that it doesn't change my game at all, it's barely noticeable.

Ah, to clarify, I was comparing Wachunga's design to my old hatch ranch design that preceded this one, based upon a 120 cycle lifespan for hatches. I didn't make that clear but somehow expected you to know. My apologies. Compared to your 103 cycle span and the 95 cycle span possible with Wachunga's design, the difference is very small. 95 versus 120 is much larger. Also i'm not really familiar with Francis John's stuff, because I abhor watching YouTube video about ONI I'll likely never become familiar with them. I've tried watching them before but I always get tired of listening after a few minutes, just not interesting enough and very meandering and tangential. Probably assumed it uses more materials. 

However, the Wachunga design is not really difficult to build at all and is more efficient than the incubator approach. It will be a while before I get to test it in a game since I have already made the design in my OP in the current base, but next time it's definitely on the list.

 

2 hours ago, Kutuluk said:

I worked on the scheme, now there is egg filtration and clearer door operation

Hello thanks for chipping in. I think it might be possible to narrow this build by 2 more tiles by moving the critter drop-offs to a spot in the area above the breeding area, and using a dropper to get critters down. Then maybe flip the underwater sweeper vertically and crunch things together down there by 2 tiles. This would narrow the 2-stable setup to 13 tiles. If you make two of these suckers for a total of 4 stables, the tile length would be 25 allowing to fit into a 26 tile wide base grid, like the one I use. Of course, if you don't have concerns on fitting it into the 26-tile wide grid then this doesn't matter.

Link to comment
Share on other sites

16 minutes ago, Satyrical364 said:

Hello thanks for chipping in. I think it might be possible to narrow this build by 2 more tiles by moving the critter drop-offs to a spot in the area above the breeding area, and using a dropper to get critters down. Then maybe flip the underwater sweeper vertically and crunch things together down there by 2 tiles. This would narrow the 2-stable setup to 13 tiles. If you make two of these suckers for a total of 4 stables, the tile length would be 25 allowing to fit into a 26 tile wide base grid, like the one I use. Of course, if you don't have concerns on fitting it into the 26-tile wide grid then this doesn't matter.

You read my mind =)

13.thumb.jpg.ae366cf943d3089321e912f7452143b7.jpg

Link to comment
Share on other sites

Correct if I am wrong. The idea of these last builds is to create an egg buffer, so if any hatches die the farm population would be replenished faster? For this purpose they use another [central] room to store some eggs and use door and critter movement mechanism to allow them to get back?

is there more numbers/info on this?
 

On 8/15/2020 at 8:25 AM, Lifegrow said:

Hey bud, I was a fan of the last build - I've tinkered and used it ever since.

The changes to chutes being automated and opened/closed simplified my build a lot (no shutoffs needed) - however I still opt for a central egg dumping/sorting/drowning area as I feel it's cleaner. For the dropper doors I just use a timer on default settings 10/10 and it works beautifully :D 


image.thumb.png.b3e061d7ee03f98bded031dfabf921c6.png
 

The only downside I can see with your build is the initial setup, the part where your eggs aren't naturally staggered - theres a *chance* multiple eggs could hatch at the same time and drop multiples - but other than that it seems clean :) 

Can you explain your build?

Do you use a section of the conveyor as the buffer and drop eggs as need through the shute? 
Your drop is within the stable, unlike the other builds, why separate it and use the elaborate door drop mechanism instead of just dropping the egg down to the stable?

 

EDIT: do eggs on conveyor rail incubate?

Link to comment
Share on other sites

1 hour ago, Cipupec2 said:

Correct if I am wrong. The idea of these last builds is to create an egg buffer, so if any hatches die the farm population would be replenished faster? For this purpose they use another [central] room to store some eggs and use door and critter movement mechanism to allow them to get back?

There are various factors that make a ranch underperform compared to the theoretical max output.

I like to look at it this way: forget about critters, think of "slots" inside a stable. In a 96 tile stable there are 8 slots.

Each of these slots produce 1 egg every 6 cycle. So each slot can in theory produce 1/6 egg/cy, or 1/6 * 4000 kcal/cy (the time it takes to hatch, evolve, be cooked does not affect the rate of production). That's 666.67 kcal/cy or enough food for 0.66667 dups. That's our upper limit. The inverse is 1.5 critter slots per dup.

Let's see what can affect production rate and lower it. The slot has to be occupied (all the time) by a critter that is adult, tamed, happy. Happy means groomed, fed, and w/o other reproduction affecting debuffs (like "cramped").

The minor things (delays in seconds) are:

- it take a few seconds for eggs to be removed, and technically the 8 critters are "cramped" and all egg production pauses for that time; we usually consider this irrelevant, in a proper build sweepers take care of that. All you have to make sure is not to route rails thru stables (that is, have the eggs delivered outside the stables ASAP);

- once the groomed effect expires, it takes a while before a dup arrives and it takes a while (the whole grooming animation) before the effect is applied again; this is not insignificant, IMHO, but few builds optimize for that. I can't think of ways of doing it w/o trapping multiple ranchers in the whereabouts of the stables, with food, bathrooms, bedrooms and all, and have them idle in there, always ready to intervene. You also arrange the stable to minimize the waiting time but I've read reports from people that it hardly makes any difference in the duration of the animation. YMMV I guess. Nothing can be done to further reduce the animation time, and that means that the 1.5 ratio is unobtainable. The groomed effect applied by dups with high husbandry does last a bit longer, and the animation happens less often. But training your dups in husbandry is not easy, and probably saves you only a few seconds/cycle.

The major things (delays in cycles) are:

- once a critter dies, the corresponding slot is empty, and the stable operates at 7/8 capacity. Here you have to wait for a egg to hatch, and a dup to deliver the baby.

- the baby has to grow past age 5 and become an adult. For all that time, the slot is not operational, as reproduction rate for babies is 0%.

We're talking many cycles of lost productivity here, potentially. For each slot.

A standard build (i.e. if you follow Francis Jonh's tutorial on YT) addresses these factors is a suboptimal way. By using several unpowered incubators, you relay on chance. It's highly probable that a egg hatches soon enough (if you have 10 incubators, the average waiting time is 2 cycles only), and given that babies stay in incubators for a while, it's possible that a slot has to wait less that 5 cycles to become operational again. So the average waiting time less that 7 cycles. Still, it's (less than) 102 cycles vs 95, or (less than) 7.3% loss in efficiency. Meaning you need (less than) 1.61 slots per dup instead of 1.5. The precise number is hard to compute, and it depends on the number of incubators, so it's of little interest here. I tend to play safe (by large) and use 1.75. 

@wachunga's build is a very optimized one. Basicly if you manage to deliver an adult right after one critter dies, you can approach the ideal 1.5 figure.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...