• Content Count

  • Joined

  • Last visited

Community Reputation

459 Excellent

1 Follower

About wachunga

  • Rank
    Senior Member

Recent Profile Visitors

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

  1. At a certain liquid level they won't path back in but also don't drown. I forget what the break points are exactly, but 350kg works for water. This was my initial thinking. I never experimented with stacked liquids and there may be an elegant solution using them. Judging by your ranch layout, I'm guessing you have them off on the wings of your base. Or maybe I'm projecting. Typically I have a central column of rooms with ladder shafts on either side and then more rooms, including ranches, on the other side of the ladders. Another idea is to stick 2 ranches in such a central column feeding off eggs delivered from both sides. Uses 2 floors but maintains the 4 height overall floor plan, can stick whatever in the extra space. 150kg seems to be a good number for crude. Note I didn't test either of these exhaustively, might be things I overlooked. Edit: Yeah, forgot about endless egg cycling, sweepers/loaders would need to be moved/blocked to prevent a loop. Also loader/rails should be placed to get eggs out of the room ASAP. In the first example, the inner door could probably be rotated vertically with a stacked liquid and eggs dropped into it for more compactness and less liquid usage. The same style as you have. Edit Edit: Last one I promise. Eggs from 4 ranches being split between top 2 and bottom 2. And then left or right as needed. Should be good for spreading eggs out evenly and giving minimal downtime.
  2. I particularly like the drecko sorting. An immediate thought that comes to mind is figuring a way to include moats to keep them off the ceilings and potentially reduce rancher wait time. You may have already seen this, but if not: My original thought is further up the thread and the OP has a dropper design that is interesting if not applicable. I eventually ran a base for 300+ cycles using a design very close to the post I linked. It worked great, but I lost patience with the grooming bug and dupes stealing sweeper jobs. I abandoned the game after testing the ranch sufficiently. The 5 cycles as a baby isn't that big of a deal in the grand scheme of things, but you could insert such a system (maintaining a glum adult critter ready to go) in your 4 high rooms if you wanted to chase efficiency. If I were to do it again, I would maintain the same overall design but endeavor to use only 1 chute location and allow babies to go to either side depending on which stable needed it.
  3. @OxCD I think you are misunderstanding how the system works. The point of the looping isn't to add time for disinfection. Going straight through kills all germs. The looping is to keep the reservoirs full. Full reservoirs is what kills the germs. Germ death is percentage based. The more liquid you have in a reservoir, the more germs. The more germs you have, the more die off per second. This plus the dilution from taking 10 kg out of 5,000 kg and adding it to a different 5,000 kg kills all the germs. You could make the same system without a loop using a shutoff and a liquid backup detector, but the loop is a very simple way to do this automatically.
  4. I had to modify values in solid.yaml to see the difference. Upon further testing 0.001 conductivity isn't needed. You can do something like 1 (depending on other values) and see the building portion change some but not as much as the solid portion did. Maybe it's 40000/65025 (200/255 squared) and the 0.01 squared. Or maybe it was fixed for the DLC. My coding experience was years and years ago, I'm not up to the task of compiling a mod to check myself. It's all very strange.
  5. In the back of my mind I knew you went through all the same stuff and I was being a gas bag.
  6. But my testing shows that isn't the case. The intention may have been to change it, but the execution did nothing. In this test I first edited these elements in solid.yaml: Obsidian: 1 SHC and 65025 conductivity Sedimentary: 1 SHC and 6 conductivity Gold: 1 SHC and 0.001 conductivity Iron: 1 SHC and 100000 conductivity The temperature values for the igneous and sedimentary are starting conditions above and after 1 tick below. Governing conductivity is the lower conductivity when insulated tiles are involved. After the 4/65025 insulation modifier, obsidian ends up at 4. With igneous at 2, the predicted heat exchange will be 2*100*200 or 40000 kDTU. This is exactly what we see with the igneous changing by exactly 4K. With sedimentary at 6, the obsidian tile now has the lower conductivity and the predicted heat exchange will be 4*100*200 or 80000kDTU. This is exactly what we see with the sedimentary changing by exactly 8K. My hypothesis for this is because buildings that act as a solid tile actually create a solid behind the building. The building itself interacts with nothing so the fact that it has a 0.01 insulation modifier means nothing. The solid behind has the conductivity of the material but is special cased with the 4/65025 modifier. There was once a bug where debris sitting on an insulated tile didn't respect the insulated property. Presumably because the special casing wasn't added to the debris/tile interaction. There are some "tile buildings" that are bugged however, see here (note that transit crossing appears to have been fixed since then): The weight plate portion of the test demonstrates this. Cell to cell conduction happens first then cell to building. Normally this interaction never happens, but for these bugged buildings it does. However you can't see it because the rate is so high. By crippling gold's conductivity we can see a difference between tile and building. Boosting iron's conductivity is necessary to get heat into the tile in the first place. The underlying gold tile has changed by exactly 4k as expected with the values I set, but the building portion remains unchanged. The summary is Klei may have intended to change how insulated tiles work. But they apparently don't understand how their game works so their change didn't actually do anything. Or maybe I'm bashing them for no good reason. They never communicate so who the hell knows. The real answer is probably that they simply don't care. It makes no financial sense to spend limited resources on things I want (fixing stuff like this) when they can pander to a much greater audience.
  7. Great stuff as usual. I've been tinkering with the same idea off and on, please excuse the brain dump that follows. At that rate you could power this with a kiln to be extra silly (keep the refinery for preheating though). Partially covering it with molten material is necessary to boost heat output from 4 kDTU to 12 KDTU. You're probably losing heat to the 1.5C boiling bug. The great thing about counterflowing 0.2 SHC against 1 SHC is that your 0.2 material comes out at virtually the same temperature as the 1 material going in. Which means in theory you only need to account for the 1.5C "heat of vaporization". With 10 kg/s of 0.2 SHC glass, that should be 3kDTU. In my fiddling, I tried this geometry to avoid the bug: The molten glass exchanges heat with the tile of rock gas before it boils and loses the 1.5C. No heat exchanges with the insulated tiles so extra 1.5C deletions (from the bug) don't happen. In practice, the steady state temperature loss you need to make up for is ~1.8C. The kiln had an uptime of ~1% for 0.12kDTU. That's less then expected. I suspect the simulation or uptime reporting starts to fall apart at this scale. You would of course have to rejigger things a bit to make room for a similar setup.
  8. The 4/65025 comes from the famous @Yothiel post from way back when. "an insulation factor noted f (dimensionless, varies between 0 (total insulation) and 255 (no insulation). Actually, this value is always 255, excepted insulated tiles which have 2." "the insulated conductivity noted k' is derived from (gasp) the insulation factor and the thermal conductivity using the following formula: k' = k * (f/255)²" As ridiculous as it seems, it still behaves that way. For me at least. The 0.01 factor only effects the displayed conductivity when selecting an insulated tile, with no meaningful relevance anywhere as far as I can tell. My test was interacting extremely hot low mass gold with insulated granite to get numbers large enough to work with. Actual results nearly match with what a 4/65025 factor would predict. I presume the minor slop comes from the extreme numbers involved. I learned my lesson from Klei's unwillingness to seriously address bugs and other issues that have existed for years. No DLC for me!
  9. @FIXBUGFIXBUGFIXLinux? Base game or DLC? For me on windows base game, the critical point is between 388 and 389 kg in your first example. I also double checked the insulation factor with insulated 20C granite vs 500g of 9020C gaseous gold. It's still 4/65025 here. Wouldn't be the first time that the sim ran differently under a different OS. Nor would it be the first time for an undocumented change during a major update.
  10. Read the second half of this thread. The TLDR summary is heat exchanges that result in a very small change in temperature don't happen. Whether this is explicitly designed or just an emergent phenomenon is unknown. In the OPs example, the amount of heat exchange remains fixed regardless of steam mass (because that's just how the game works). As the mass of steam increases, it's change in temperature per tick become less and less. At a certain point, the temperature change drops below the threshold and all heat exchange stops. The cutoff point happens somewhere between 388 and 389 kg of 150C steam interacting with a 20C insulated ceramic tile. We can do the math to see what the temperature change would be for these two masses. Temperature change = (heat exchanged)/(steam mass)/(steam SHC). Heat exchanged = (governing conductivity)*(temperature difference)*(gas to solid multiplier)*200 For 388 kg: Temperature change = ((0.62/16256.25)*130*25*200)/388000/4.179 = 0.00001529C For 389 kg: 0.00001525C
  11. Liquid properties can be found in \OxygenNotIncluded\OxygenNotIncluded_Data\StreamingAssets\elements\liquid.yaml. Flow rates and such. DefaultMass in solid.yaml determines whether freezing liquid forms as debris or a solid tile, 80% is the trigger point. Niobium for example has a very low defaultMass which creates the need for the trickery in the linked post. Presumably this was an unintended consequence of making niobium, fullerene, and isoresin rare in map generation (they all share abnormally low defaultMass). One does wonder why a niobium volcano outputs sooo much of a supposedly rare resource, but hey ho.
  12. I was just about to post some pretty pictures showing the gradual mass deletion with the range but you beat me to it! Combine this with a dispenser refilling the tile and you have a very silly way to get rid of any material you want.
  13. Maybe the same bug/typo as the gas range where it outputs the gas one tile too high. Easy to check for anyone who has happened to decompile the DLC. Same thing as debug painting a gas over a tile. The gas replaces the underlying solid but the building part of the tile still exists. It doesn't do anything because it never did anything in the first place.
  14. I was screwing around with ideas for a design that doesn't require a precooler section. Ultimately I'm not happy with it, but I thought I'd share because other might find it interesting. The goal is to slow down debris formation in any given spot. When it is forming every other tick, the debris doesn't fall fast enough to avoid the next cell of liquid niobium. If the debris isn't cool enough, it can remelt. Sometimes a newly formed piece of debris will suck in a previous pile so you get 1 ~40kg bit instead of 2 ~20 kg bits. Both of these interactions can happen or not happen depending on the game speed. Essentially an unstable situation that will likely lead to a solid niobium block eventually forming. By splitting the flow I was hoping to give the debris enough time to fall out of the way, avoiding both problematic interactions. The right side creates debris once every 6 ticks. Slow enough that it never forms 40kg or touch the next liquid niobium cell. Perfect. The left side creates once every 3 ticks. Good enough to avoid the 40kg problem but not the reheating. Kinda ok as the niobium can, in a nice consistent flow, be frozen enough to avoid remelting. The problem is this stable pattern doesn't establish itself immediately. As the column is filling you sometimes get debris forming once every 2 ticks on either side. If you happen to get unlucky during this period, solid niobium ruins your day.
  15. Here is another option. Yellow actives the pump, purple cools the pump, and red is your magma.