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.

ghkbrew

Infinite Heat by Freezing

Recommended Posts

ghkbrew    137

I've succeed in weaponizing one of the bugs @mathmanican and I explored in this thread (mostly complete description here).

662650361_FreezerFurnace-Overview.thumb.png.01f1ffaf478d1f2f9a72e2a7fb4332d1.png

Without the long line of turbines this is an efficient freeze-thaw cycler for molten aluminum operating at ~285 kg/s.

1062939543_FreezerFurnace-Detail.thumb.png.036956b88718455a1253eef3fc91437d.png

This is where the bug occurs.

In short, both the thermium tile and igneous rock tile cool the bead of molten aluminum in the lower mesh tile.  They both gain heat in the process.  The thermium tile draws as much heat as possible from the aluminum and the igneous rock is held at a constant temperature such that it draws ~3.5C worth of heat from the aluminum (just enough that it would cause the 933.5K aluminum to freeze).

The bug occurs when two tiles attempt to freeze a liquid into debris in the same tick.  The resulting debris pile has a temperature which reflects the heat exchanged with only one of the tiles. However, both of the tiles gain heat as if they had interacted with the liquid prior to freezing.  In this case the bottom tile wins out (the priority seems to be bottom, left, right, top).  This means that the heat gained by the thermium tile effectively appears out of nowhere.

In fact the heat generation of this machine could be doubled by replacing the insulated tile on the right with a second thermium tile and drawing heat from it too.

Basically the only limitation to exploiting this bug is how quickly heat can be removed from the tiles adjacent to the freezing location.

 

A nearly identical bug occurs when multiple tiles attempt to condense a gas into a droplet in the same tick.  The resulting droplet will have a temperature reflecting interaction with only one tile, but all the tiles will change as if they had interacted with the gas.

 

 

Freezer Furnace 003.sav

Share this post


Link to post
Share on other sites
mathmanican    3318
44 minutes ago, ghkbrew said:

I've succeed in weaponizing one of the bugs

You, my friend, are very good at this. (Honorable Bow)

You've got them cowering in fear!:spidercowers:

So basically, because phase changes do not appropriately allocate heat, we can massively abuse the itty-bitty amount of incorrectly placed heat. While this is another instance where conservation of energy does not apply (I'm not expecting it to in ONI), the problem here is much worse, massively exploitable, and probably rectifiable with a change in code.   

@ghkbrew, Do you want to put together a nice bug report?

Share this post


Link to post
Share on other sites
Lifegrow    1710

Awesome work @ghkbrew - a nice showcase of a jank-tastical intended game mechanic :D 

4 hours ago, mathmanican said:

and probably rectifiable with a change in code. 

Isn't this normally the case? Slightly sickens me the amount of people actively offering a direct fix and being ignored. I genuinely appreciate the work you folks do in beating down the maths/direct causes of these bugs - shame they have to be publicised on the general forums in the process.

Everything about the lengths we have to go to in order to get the devs to take note bothers me. From click-baity forums threads, to OTT builds to showcase how broken some elements of the game are. 

I very much understand the mindset of "If we show how broken these things are, maybe they'll fix it..." - the problem is, if they don't fix it, then all you've done is widely spread a bug (complete with the means to exploit it) that should have remained in the bug-tracker section.

Maybe i'm way off here, but wouldn't it be best to keep these sort of discoveries primarily in the bug tracker section? Let's face it, this thread is a humble-brag of achievement more than a discussion topic of the initial issue. Meh, just my 2cents.

Share this post


Link to post
Share on other sites
nakomaru    1665

Well, I'll say thank you for sharing the discovery and engineering. I think this is fairly harmless at worst and good to share the knowledge of tile-ordered calculations. I learned!

Share this post


Link to post
Share on other sites
TripleM999    235
8 hours ago, ghkbrew said:

In fact the heat generation of this machine could be doubled by replacing the insulated tile on the right with a second thermium tile and drawing heat from it too.

Maybe a conveyor and a wire bridge can help there to connect the other side heatwise, though i'm not sure, if it will disturb you phase change point.

Share this post


Link to post
Share on other sites
TheMule    257
3 hours ago, Lifegrow said:

all you've done is widely spread a bug (complete with the means to exploit it) that should have remained in the bug-tracker section.

Which being ONI a single user game, causes very little harm.

There's a game breaking mega bug, in ONI, called sandbox mode, even worse, debug mode.... if someone chooses to abuse other, less impacting bugs, to - idk - create infinite energy, they are just choosing a suboptimal path. You can paint everything you want, the way you want, so why even bother implementing bug-abusing builds?

I mean, why use a bug to smelt abyssalite to get tungsten for almost zero energy when you can paint tons of it? I totally get if someone wants to do that in a legit way. And that's where widespread knowledge of bugs is very useful.

Almost everybody who tamed a metal volcano in the recent past, did also abuse of the heat-deleting bug. Many builds/guides about volcano taming were simply wrong, and they actually stopped working after the patch.

So, spreading knowledge about bugs actually help people who want to avoid them.

For sure, it helped me. No tamer of mine failed, because I already did my best to avoid the heat-deleting bug - months before the fix hit - and that's only because I was aware of it, thanks to @Tonyroid.

Share this post


Link to post
Share on other sites
0xFADE    547

Very clean design.  I was wondering how much you could get out of those tests you were doing with single tiles around something but I was proven wrong.  Very nice.

1 hour ago, TheMule said:

Almost everybody who tamed a metal volcano in the recent past, did also abuse of the heat-deleting bug. Many builds/guides about volcano taming were simply wrong, and they actually stopped working after the patch.

I've been using a slight change to a Brothgar design for metal volcanos.  Dropping it on to a door and pulling the heat out then further cooling it off beneath the door.  Pretty sure it wasn't using any bugs but i'll have to find out.  If anything, if this specific bug is happening it is just making it harder to cool off the metal since it is generating more heat than it should.

Share this post


Link to post
Share on other sites
ghkbrew    137
9 hours ago, mathmanican said:

@ghkbrew, Do you want to put together a nice bug report?

I'll see what I can do.

2 hours ago, TripleM999 said:

Maybe a conveyor and a wire bridge can help there to connect the other side heatwise, though i'm not sure, if it will disturb you phase change point.

I did briefly try this.  The resulting aluminum debris started coming out coming out much colder.  I suspect the interaction with the building (conveyor bridge) was taking precedence over the bottom tile. 

I gave up on the idea because I'm pretty sure it wouldn't really help much, anyway.  The heat generated by the thermium tile is proportional to the difference between it's temperature and the molten aluminum.  So a colder tile will generate more heat than a warm one.  Dumping heat from the right tile to the left will increase it's temperature, which will help conduction away slightly, but will also decrease the heat generated.  Those two effects should about balance out, I think.

Share this post


Link to post
Share on other sites
mathmanican    3318
6 hours ago, Lifegrow said:

Maybe i'm way off here, but wouldn't it be best to keep these sort of discoveries primarily in the bug tracker section?

A respectable opinion. I disagree with the suggestion completely. 

The bug tracker section is where I place information to help the devs.  I generally don't try to have a conversation over there with other forum members. These sort of collaborative conversations are precisely what leads to this post by @ghkbrew. I put summarized details in the bug tracker, and open encourage memes, rants, etc., over here in the forums.  

2 hours ago, TheMule said:

spreading knowledge about bugs actually help people who want to avoid them.

This is what I firmly believe as well.  When i want to design a "good" build, I want to know EXACTLY why something fails. I'm not satisfied with a "here is a workaround that seems to resolve the issue."  I want to know precisely the root cause. Discussions like this have, over the last 3 months, yielded quite a bit of new knowledge about the game. 

I'm going to guess that the devs, like @0xFADE said, don't realize the shear devastating power of a single tiny bug. 

1 hour ago, 0xFADE said:

I was wondering how much you could get out of those tests you were doing with single tiles around something but I was proven wrong.

It is only when we put together builds like this, or @TripleM999's Borgie, or @Zarquan's liquid hydrogen flaker, or my doomsday freezer, or @Saturnus's borg cube, etc., that the shear potential of these bugs is realized. @FIXBUGFIXBUGFIX was extremely good at posting detailed bug reports, with decompiled code snippets showing what exactly caused the bug. However, if it's a bug that supposedly can happen "only under very specific conditions", then why fix it? That may be the philosophy behind why the devs don't change the code for every bug. (Astronauts never leaving their spaceship?) Only after fine tuning the gaseous matter conversion bug, and then realizing it happens everywhere, in every game, in every base (without trying to make it happen), did the devs take notice. Same thing happened with the water duplicator, and more. 

It take a community discussion to fully realize what the implications of intended mechanics are.  Whether the devs want these implications to live on as emergent gameplay or squash them as bugs is their choice.  I value posts like this because they help all of us realize the consequences of the current state of the game. 

6 hours ago, Lifegrow said:

this thread is a humble-brag of achievement more than a discussion topic of the initial issue.

To me, this thread is a culmination of organizing topics.  It's a clean post that takes very little effort to read. It provides a new starting point for those that want to join the discussion, without having to wade through a 7 page dissertation (like the heat deletion thread).

@ghkbrew, thank you for your work. This bug, with phase changes, is guaranteed to afflict every base, every game. It means that every build that involves a phase change (don't most) have to account for it. It also means that building things in sandbox, using insulation, will NEVER achieve similar results as ingame builds that use ceramic.

In particular, one thing this thread has helped me see relates to the steam turbine designs. I gave a "fix" to the phase change bug that is wrong. I suggested that putting stuff cooler than 95C around the vent on 3 sides would prevent the bug.  That is flat out wrong.  The key is to make sure that the stuff around the vent cannot exchange temperature with the 95C liquid. Without insulated insulation, I have to make sure that whatever heat conduction should occur is below the 0.0001?? threshold that results in zero transfer (ceramic might not be good enough).

 

@ghkbrew, I loved this little bit.

image.png.29cca8065758f2b13c60740ce316eae8.png

I assume this is how you throttle it to 285kg/s, as it wants to move much, much,  faster.  So at this speed you have about 57kg/tick flow, which means the beads are falling at around 114kg/bead (less than the 160kg at which things solidify for aluminum).  Did you try deleting another tile to see if you could get this up higher, and then a bead froze into a solid block?

Another option, that might increase the speed by double, is to swap the side off which things flow, and use a waterfall instead of beads.  The waterfall does not bunch up double the liquid when things fall. This might allow you to increase the flow rate to 500kg/s (aluminum's max since viscosity = 100). The only worry then is backflow heat transfer, which may cause problems, and may ruin things as then you have liquid instead of vacuum above the phase-changed liquid.  Might be worth a try if you want to increase the flow rate. 

With lead, it did not matter if I used waterfalls or beads (as solidifying in solid chunks happens well above the max flow rate).  With aluminum, these two matter.  I should probably return to my heat doubler and redesign (maybe I can get a full 500kg/s). 

Share this post


Link to post
Share on other sites
0xFADE    547

It is a rather crazy amount of aluminum, that in itself makes this build harder to do.  Still it often takes a fully realized design before a bug will be taken seriously.

Share this post


Link to post
Share on other sites
ghkbrew    137
2 hours ago, mathmanican said:

I assume this is how you throttle it to 285kg/s, as it wants to move much, much,  faster.  So at this speed you have about 57kg/tick flow, which means the beads are falling at around 114kg/bead (less than the 160kg at which things solidify for aluminum).

That's it exactly.

2 hours ago, mathmanican said:

Did you try deleting another tile to see if you could get this up higher, and then a bead froze into a solid block?

I didn't play with that much, but my impression was that the length of the run after the door didn't really change the total throughput.  The reason I made it so long was to even out the bursty flow through the door.  Even with the fastest cycle (1s open / 1s closed) when I had the door on the right side of the tank I was getting individual beads larger 160kg (which froze into solid blocks and gummed everything up). I just said screw it and moved it to the far left of my tank, which worked so I didn't mess with it.

If you wanted to increase throughput with this design my thought would be to move to 3s open / 2s closed, but you'll still need the long run or even longer.

2 hours ago, mathmanican said:

Another option, that might increase the speed by double, is to swap the side off which things flow, and use a waterfall instead of beads.  The waterfall does not bunch up double the liquid when things fall. This might allow you to increase the flow rate to 500kg/s (aluminum's max since viscosity = 100).

Ha, way ahead of you these are what I'm playing with right now:

1651722927_AluminumCyclerPrototype1.thumb.png.82be71a83b4b86d77647a5d9578969cd.png1129891674_AluminumCyclerPrototype2.thumb.png.3cabf3c5426f84771c1d567274ed9834.png

The left/right double waterfall provides constant 100kg/tick (500kg/s) flow no matter how much you dump on top of it. This also mitigages @0xFADE's concern about the amount of aluminum in the build.  The right side design only has about 15tons of aluminum in it (and it keeps backing up because of the bursts when the debris melts)

 

2 hours ago, mathmanican said:

The only worry then is backflow heat transfer, which may cause problems, and may ruin things as then you have liquid instead of vacuum above the phase-changed liquid. 

I don't backflow is too much of a worry.  Both the cooler and the heater are perfectly thermally isolated.  Liquid never sits in the cooler for more than a tick so it doesn't have time to send chill backwards.  The heater is vacuum insulated (unless the molten aluminum backs up enough to touch the doors, which is bad regardless)

Edit: turns out the upper left blob of lead is entirely unnessary and removing it stops my back up issues

 

Share this post


Link to post
Share on other sites
Zarquan    1006
2 hours ago, mathmanican said:

It is only when we put together builds like this, or @TripleM999's Borgie, or @Zarquan's liquid hydrogen flaker, or my doomsday freezer, or @Saturnus's borg cube, etc., that the shear potential of these bugs is realized. @FIXBUGFIXBUGFIX was extremely good at posting detailed bug reports, with decompiled code snippets showing what exactly caused the bug. However, if it's a bug that supposedly can happen "only under very specific conditions", then why fix it? That may be the philosophy behind why the devs don't change the code for every bug. (Astronauts never leaving their spaceship?) Only after fine tuning the gaseous matter conversion bug, and then realizing it happens everywhere, in every game, in every base (without trying to make it happen), did the devs take notice. Same thing happened with the water duplicator, and more. 

It take a community discussion to fully realize what the implications of intended mechanics are.  Whether the devs want these implications to live on as emergent gameplay or squash them as bugs is their choice.  I value posts like this because they help all of us realize the consequences of the current state of the game. 

And this is probably the right way for the devs to go about it.  Why put debugging time in to some arcane nonsense that can generate or delete tiny amounts of heat that they believe probably occurs in nature or natural play a only few times.  Tracking down and fixing bugs is an expensive process and can often break more things than it fixes if you don't do it perfectly.

When we find a bug which they thought was small and show how prevalent and problematic it is, that makes it a lot easier for them to justify fixing it.  "Oh, the messed up flaking math causes problems outside abyssalite boiling more sour gas than it should?  You created a doomsday device that can freeze the whole world to -260 C with no power?  And you told us exactly where the bug is?  We should fix it!" 

This is, in my mind, more motivating than "A weird thing happened that I don't understand that effected me once.  Please fix."  Because the fact that it effected the player once and they needed a specific process to create the problem means the problem probably isn't that prevalent.

Share this post


Link to post
Share on other sites
SamLogan    974
8 hours ago, Lifegrow said:

Awesome work @ghkbrew - a nice showcase of a jank-tastical intended game mechanic :D 

Isn't this normally the case? Slightly sickens me the amount of people actively offering a direct fix and being ignored. I genuinely appreciate the work you folks do in beating down the maths/direct causes of these bugs - shame they have to be publicised on the general forums in the process.

Everything about the lengths we have to go to in order to get the devs to take note bothers me. From click-baity forums threads, to OTT builds to showcase how broken some elements of the game are. 

I very much understand the mindset of "If we show how broken these things are, maybe they'll fix it..." - the problem is, if they don't fix it, then all you've done is widely spread a bug (complete with the means to exploit it) that should have remained in the bug-tracker section.

Maybe i'm way off here, but wouldn't it be best to keep these sort of discoveries primarily in the bug tracker section? Let's face it, this thread is a humble-brag of achievement more than a discussion topic of the initial issue. Meh, just my 2cents.

I feel your message isn't not fair to the developpers. You have to consider few things :

- When you change a portion of a code, you generate new bugs because in a code everything is link and you have to have a general view with potential consenquences of a change. As ONI have a lot of complex sytem, it's really hard to anticipate the effect of a local fix. As an outside person, it's easy to fix few lign of code, but you don't know which will be the result overall.

- Klei is a small dev team, so they have to priorize the bug fix and often those bugs are affecting only advanced players.

- They also have to work on the DLC, so maybe take a step back in your way to see thing, even if you are a great contributor.

Share this post


Link to post
Share on other sites
mathmanican    3318
57 minutes ago, ghkbrew said:

turns out the upper left blob of lead is entirely unnessary and removing it stops my back up issues

It may be needed to jump start the contraption (though there are other methods).  Once it's running, things should work fine.  The blobs of lead just help get the conditions set up to enable waterfalls and/or beads.  

1 hour ago, ghkbrew said:

Liquid never sits in the cooler for more than a tick so it doesn't have time to send chill backwards.

Thanks.  You are right. Since liquid is only there for 1 tick, then it will enter the one-tile cooler at full temp (hence not sending cool upwards via conduction), and then transform to solid before it ever gets to exchange heat.  I thought for a second that you might loose 1 tick of heat, but that is false. 

1 hour ago, ghkbrew said:

these are what I'm playing with right now

I'm loving watching you play with liquid mechanics. Please keep sharing. 

Have you played with a liquefying and reheating, all in one tile?  Similar to what I posted on page 2 and 3 of the molten lead for the win post. 

image.png.4ccac26239dbe0cea14260ad796028cf.png 

I haven't gone back to exploring this more (been busy), but something that works along these lines means we could extract the phase change heat in an itty-bity box, at which point @0xFADE's concern would be gone. 

2 hours ago, 0xFADE said:

It is a rather crazy amount of aluminum

It would also mean we could build such a crazy device anywhere, with almost no materials, and definitely help elevate the issue in terms of priorities, as @Zarquan eloquently stated above. :) 

Share this post


Link to post
Share on other sites
0xFADE    547

The crazy amount of aluminum was more of an offhand statement, that buffer in the first image wouldn't need to be that huge.  Still, you would need to be on a map that had aluminum, or space targets.

Share this post


Link to post
Share on other sites
mathmanican    3318
12 minutes ago, 0xFADE said:

you would need to be on a map that had aluminum

You could do the same with lead, just would not be as pronounced.  There are alternatives :)  You can also do this with water, on Rime, if you want the entire asteroid to get to 0C. 

Share this post


Link to post
Share on other sites
TheMule    257
51 minutes ago, SamLogan said:

When you change a portion of a code, you generate new bugs

This. Well, it's not that you for sure generate new bugs, but there's a chance to. And the new bug could be worse than the one you fix. So it makes sense to make sure the bug is relevant enough before you fix it. After all the road to hell is paved with good intentions.

5 hours ago, 0xFADE said:

I've been using a slight change to a Brothgar design for metal volcanos.  Dropping it on to a door and pulling the heat out then further cooling it off beneath the door.  Pretty sure it wasn't using any bugs but i'll have to find out.

I think I'm familiar with it... is it this one?

https://youtu.be/jFpxZH2-Pn0?list=PL2gmcIorFri-2pm5qfyUuy18biSaf-wgz&t=132

Unfortunately that doesn't address the cooling of the turbine. If not cooled, it's going to overheat for sure today, given the amount of water he puts inside the chamber, heat deletion was bound to happen, reducing the need to cool down the turbine at the time.

Builds based on active cooling with an AT are not "failing" directly today, just they suddenly require more energy (which may or may not be a problem).

A suspicious build would be this one:

https://youtu.be/O-YYEVvHriw

expecially for the iron volcano. That build failed me when I modified it as per @Tonyroid's suggestion back in the days. 3 STs turned out to be barely enough. Actually 1ST actively cooled struggles keeping the temp below 200C even with a lot of steam. My to go build for strong iron volcanos now is 2STs, actively cooled.

This is a nice example of a totally unintended use of a bug.

Share this post


Link to post
Share on other sites
mathmanican    3318
55 minutes ago, SamLogan said:

they have to priorize

Spot on @SamLogan.

For the reasons you gave above, I have stopped expecting fixes, as I think this expectation is where being unfair to the devs begins. I assume they'll prioritize what they deem as most important (balancing quality/cost/time/new stuff/etc.) I know they read the Klei forums (have no clue about the others). 

I'll play with the things that I find fun and are currently important to me (which often has zero connection to the rest of the gaming community). Most of my contributions can be traced to me trying to build something that should work, only to find it does not behave as I expected. Then I explore the "why it failed" part. This includes tons of stuff, some useful contributions, some massive bug exploits, and some just random facts that help other places.  

Sometimes I hope (but don't expect) that crazy builds get their attention and underlying bugs get fixed.  @Blazing Falken's work last year with the fridge cooler is extremely simple to abuse, but they devs never picked up interest. @wachunga started another thread related to that work. Maybe they'll tackle it someday, maybe not. 

What I see is people passionate about making cool builds, who find bugs that hinder their builds, and want to help improve the game. Some of us get more excited than others about massive abuses. A tiny bug report buried in the pile of 11,048 others (and growing), with sometimes an occasional comment or two, is easy to ignore.  A general forum post that goes on for 7 pages, has 10+ active participants, with links coming from discord, reddit, and steam, draws more attention. 

When I see the devs actively working on something, and they actually give feedback, it makes me want to focus on that issue. The devs have never picked up interest on this phase change bug, and it may get completely ignored. However, if reproducing an exploit become incredibly easy, then we'll probably be able to detect places it affects in all kinds of builds, explain lots of things that before seemed like just "rounding error", and maybe get the devs to look into fix.

4 hours ago, ghkbrew said:

I'll see what I can do.

Here is a link to a bug report that I submitted when we noticed it in steam turbines.  I think you could put together a more complete bug report, and just link to this one (so they know they are the same). 

Spoiler

 

 

Share this post


Link to post
Share on other sites
ghkbrew    137
1 hour ago, mathmanican said:

I'm loving watching you play with liquid mechanics. Please keep sharing. 

I'm glad you're enjoying it.  I'm certainly having a blast. :) at some point maybe I should go back and get to the late game in survival... maybe launch my first rocket.

1 hour ago, mathmanican said:

Have you played with a liquefying and reheating, all in one tile?

Not yet, but that's certainly on the todo list.  At the moment I'm going down the rabbit hole of counter flow heat exchanges (for 1.5C temperature deltas) between molten and solid lead.

43 minutes ago, mathmanican said:

You can also do this with water, on Rime, if you want the entire asteroid to get to 0C. 

Or if you want to make you're own Rime: super cool 1kg of water to 1K in a pipe.  Emit it surrounded by metal tiles which will each dump 270C * SHC of water of heat into it and one ceramic tile (on the bottom).  The resulting ice will be 2.5K.  melt the ice (cooling more stuff in the process) and repeat. 

Share this post


Link to post
Share on other sites
mathmanican    3318
5 minutes ago, ghkbrew said:

maybe I should go back and get to the late game in survival

I'm still working on that goal.  Haven't yet made it. :)  I keep getting side tracked by machines not quite working. I was going pretty well, till I wanted to fully understand the heating plate on my 90kg/s petro boiler that uses escher water falls.

By the time I get back to my base, a few patches have rolled out and I'm ready to start over. Someday, maybe, I'll fully launch a rocket.  I have launched rockets several times in debug, to play with mechanics, but never got there in survival. (It also might have to do with the fact that I have an 8GB potato, and I'm not sure how it will handle the lag.) 

9 minutes ago, ghkbrew said:

counter flow heat exchanges

I'm excited to see it.  I assume you are aware of this bug. It amplifies heat differences because of an average value formula being off.  It may even be usable to squeeze a tad bit of extra heat out (even at 1.5C delta), but probably not.

  

Share this post


Link to post
Share on other sites
0xFADE    547
46 minutes ago, TheMule said:

I think I'm familiar with it... is it this one?

https://youtu.be/jFpxZH2-Pn0?list=PL2gmcIorFri-2pm5qfyUuy18biSaf-wgz&t=132

Unfortunately that doesn't address the cooling of the turbine. If not cooled, it's going to overheat for sure today, given the amount of water he puts inside the chamber, heat deletion was bound to happen, reducing the need to cool down the turbine at the time.

Yes, and I have a number of changes, like having an aquatuner in the steam room that cools liquid for the steam generator and the area the metal drops to get the final heat pulled out.  You can move the temp tester inside the steam room to make the design simpler among other things.

1 hour ago, mathmanican said:

You could do the same with lead, just would not be as pronounced.  There are alternatives :)  You can also do this with water, on Rime, if you want the entire asteroid to get to 0C. 

Is it something you could do with... sulfur?

Share this post


Link to post
Share on other sites
TheMule    257
3 hours ago, 0xFADE said:

like having an aquatuner in the steam room that cools liquid for the steam generator

If it's active cooled it's a different story. The fix just makes the AT work a little more than before.

Share this post


Link to post
Share on other sites
0xFADE    547

I have not bothered getting all the pressures correct to make self cooled steam rooms work.  So yes, it is actively cooled.

I usually build it in the other direction but I am against the edge of the map with this volcano.  It conveys the metal through the lower tiles and the metal comes out under 20c.  The aquatuner will turn off if the volcano is active because it will overheat if it is running while it is also pulling heat from the metal.

Spoiler

20200724201050_1.thumb.jpg.3f17b222b701886b83e5f9a3fdd42dea.jpg

Spoiler

20200724201107_1.thumb.jpg.fa1e86d471cf1510b55e7948535ee473.jpg

Spoiler

20200724201152_1.thumb.jpg.b356a9ca3d8d62e30ae9e211ddcfe83e.jpg

 

Share this post


Link to post
Share on other sites