wachunga

  • Content Count

    266
  • Joined

  • Last visited

Community Reputation

380 Excellent

1 Follower

About wachunga

  • Rank
    Member
...

Recent Profile Visitors

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

Enable
  1. Free flowing high pressure gas is surprisingly good due to the hidden 25x multiplier for gas to solid cells. Lets say the heat is being used for turbines and the working fluid is being returned at 100C for ease of comparison: Flaking 100C liquid supercoolant to 439.85C gaseous supercoolant is 14,342 kJ of heat transfer per tick. (8.44*5*339.85), SHC*Mass*TempDelta. Igneous @ 500C conducting to Steam @ 100C is 1,213 kJ. (SQRT(2*.184)*25*400*0.2), ConductivityGeoMean*GasToSolidMultiplier*TempDelta*Constant. Aluminum @ 500C conducting to Steam @ 100C is 12,283 kJ. (SQRT(205*.184)*25*400*0.2) Thermium @ 500C conducting to Steam @ 100C is 25,450 kJ. (SQRT(220*.184)*25*2*400*0.2), thermium adds another hidden 2x multiplier. If the heat source was a thermium block instead of igneous or if you contrived a way to very quickly dump heat from the igneous to thermium, simple cell-cell conduction beats out supercoolant flaking. The question then becomes can you contrive more thermium to steam conductions or supercoolant flaking points. Of course it's not that simple. In an igneous to thermium to steam chain, the thermium will be at some equilibrium instead of 500C. And we didn't even look at using shift plate or bridges!
  2. For what it's worth, I also have issues with unwanted dripping doing the door thing. If one really wants to make a gold waterfall for whatever reason, I think the robust way of doing so would be to pre-cool the gold enough so you can float it off molten lead. AFAIK that always produces a bead. Lead's boiling point is sufficiently high to run a petroleum boiler, or a sour gas boiler, or even a regolith melter. Only really crazy shenanigans would be out of reach. That said, I agree there are better ways to extract heat from molten gold. Which isn't to poo poo the discussion, it's an interesting and valuable learning opportunity. Personally I dislike the "just a room of steam" method shown in the Francis John video as it seems potentially susceptible to the debris solidification bug. The iron volcano in the video seems to be triggering the bug for example. Maybe not a big deal in the grand scheme of things, but it's like nails on a chalkboard to me. I would advocate adding a layer of crude. The volcano metal materializes on top of the crude and floats there. Metal debris sinks fast enough to avoid the bug. As a bonus, the crude is a convenient way to add thermal mass and sucks heat out of the debris faster than steam. Swap the crude with molten lead to enable boilers.
  3. Update to add a different style of test demonstrating the bug. Shamelessly stolen from @ghkbrew's debris furnace. Super cooled molten lead falls either as the drip animation or as a bead. When as a bead, the molten lead solidifies in mid air forming a falling debris pile. When as the drip animation, the molten lead solidifies directly on top of the insulated tile where the existing pile already sits. Both piles started as 1kg @ 300C. The bead pile quickly lowers in temperature as new cold lead is merged with it. The drip animation pile incorrectly stays at 300C. Load save, flip switch, unpause, and observe the pile temperatures. Drip Debris Bug 2.sav
  4. Interesting phenomena. Here's some data and conclusions from two different tests to help out. In the top test each sweeper group pulls from one pile and puts in one bin. The sweeper cycles through 3 activities. Picking up Sandstone, Storing Sandstone, and Storing materials. Used alt= to advance per frame and counted number of frames in each activity. Game was running at approximately 80 fps (important), counts varied by a couple frames +/-. 1 sweeper: 126 frames in Picking up Sandstone, 128 frames in Storing Sandstone, and 68 frames in Storing materials. 2 sweepers: 67, 66, and 28. 3 sweepers: 45, 47, and 68. 4 sweepers: 36, 33, and 8. Picking up and the first Storing appear to simply be the task time divided the number of sweepers (roughly). The second Storing took me a bit to figure out, but it looks like the time needed to get to the next whole second. 1 sweeper spends ~3.2 seconds picking up and storing, then another ~0.8 seconds in the second storing. My guess is that the sweeper only looks for a task once a second, after finishing a task it idles until the next second comes around. This idling time is the Storing materials in the status display. Bottom test explored the Picking up and Storing tasks. Sweepers picked up from separate piles and delivered to the same bin. Or picked up from the same pile and delivered to separate bins. 2piles1bin: 125 frames Picking up Sandstone, 65 frames Storing Sandstone, and 48 frames Storing materials. 1pile2bins: 67, 125, and 48. Again the tasks with multiple users are divided by the number of users and the second storing task is the time to the next whole second. My overall conclusion is something like each animation has a timer for how long it should run. Each frame this timer is advanced with the time elapsed since the last frame. The bug being that each dupe/sweeper interacting with the object advances all the timers instead of just their own. Or maybe they all share the same timer. Or something like that. Do we all remember the offscreen bunker door animation issue?
  5. There is a bug where critters get locked into a glum state because errands to groom them stop being created for some reason. I finally stumbled upon it with a save nearby that reliably reproduces the bug. Load TestBefore.sav and select the hatch of age 50 with 0.6 cycles left in it's groomed status. When the groomed status runs out, no new errand is generated to groom the now glum hatch. The interesting and hopefully helpful bit is that a save from a few moments after the above save doesn't trigger the bug. TestAfter.sav The difference between the saves as far as I can tell is that a hatch in the ranch dies of old age. Here is a previous bug report:
  6. 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.
  7. 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
  8. 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. 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.
  9. An interesting and un-intuitive quirk is that aluminum ore bridges can be superior to steel bridges. Multiple cell buildings have clamping based on temperature change. In some (many? few?) cases, this clamping is the limiting factor and not conductivity. In such situations, higher SHC allows more heat transfer before this temperature change clamping kicks in. Of course aluminum ore has a much lower melting point than steel and may not always be usable. Taking this to an extreme, there are scenarios where shift plates made of dirt or even plastic move more heat than one made of diamond. To confuse the issue even further, some builds may transition back and forth from a conductivity limited regime to a heat capacity limited regime.
  10. From the famous decrypting heat transfer thread. I've read it so many times and relearned all sorts of stuff I've forgotten. The problem is I've forgotten what I've forgotten. Code still looks largely the same all this time later. The excess heat mechanic is a goofy one. Look at the polymer press, 32.5kdtu/s but only 500 as excess. The other 32k heats the building and must be shed as building<->cell conduction. When combined with how important SHC is with hot building conduction, you get gold polymer presses that overheat readily. Because gold has terrible SHC. If you want a brain workout, try to figure out how multiple cell buildings conduct heat. SHC is doubly important there, what a mess is all I can say.
  11. Follow up to my kiln post. I ran a few tests to explore the excess produced mechanic. Top kiln is in vacuum, middle has a blob of 50kg molten lead, bottom has 50kg molten steel on top of 50kg molten lead. Everything started at 1400K with enough coal to do 20 jobs of refined carbon, or 800 seconds worth of running. Final temps and heat production rate by doing all the math with heat capacities and such: Top: 1563.9K, ~4 kdtu/s Middle:1647.3, ~8 kdtu/s Bottom:1613K, ~12 kdtu/s So it seems the excess produced heat is evenly split across the building footprint (in this case 16 kdtu/s between 4 cells). Potential heat is lost for each of those cells that is vacuum. Meaning you can triple the heat production of a kiln in vacuum by putting liquids on it in the right places. Note I originally used 1kg of liquids and got 2.7 kdtu/s per cell instead of 4. Perhaps there is some kind of clamping going on.
  12. Kilns are a two wide building so you could stick a bit of molten lead or something on the cell that doesn't contain the building contents. IMO, the bigger issue with kilns in vacuum is that most of the kiln heat is "Excess produced" which directly heats the surrounding gas/liquid. When in vacuum, this heating doesn't happen. I never bothered figuring out exactly what happens in a partial vacuum. Does a percentage of the excess produced heat the molten lead? What percentage? Could you stack two different liquids to double that percentage? And so on. Something you might find interesting to look into.
  13. If you consider that a bridge trickplay, we live in very different realities. Any further conversation will be entirely fruitless.
  14. Tepidizers. I think that's why they were put in the game in the first place? Since you asked, this is what I do when I want to kill off germs. I like this method because there is an ongoing cost (nothing should be free), the counterflow engineering is an exercise in minimizing the cost. The reservoirs are because I hate overpressure storage. I would not recommend this build unless the person I'm talking to shares my idiosyncrasies.
  15. This isn't true. There is a feed back loop, liquid exits the system only when liquid enters the system. I cleaned up the piping from the post @nakomarulinked. I don't do the reservoir in chlorine thing because I personally think it's dumb. But if you are going to do it, this is the brain dead simple way. I share his bafflement in why people keep making Rube Goldberg contraptions. Not a knock against @Neotuck's which is pretty darn simple also, I wanted to try to clear up what is apparently a common misconception. It reminds me of when pipe sensor/shutoff filters were first put in. People swore up and down they were broken. Of course they worked perfectly fine when built properly, people just refused to listen (and still occasionally do) for whatever reason.