Jump to content

Love it and leave it (LILI) cool steam vent - help simplifying automation?


Recommended Posts

So... I recently built my self a love-it-and-leave-it (LILI? :) ) natural gas geyser (which was most definetely inspired by several designs here on the forums, but I've been browsing so much this last couple of weeks I really can't remember the different threads that gave me the idea). It uses the "standard" door compressor to store the NatGas (in a room built out of doors; which some might consider a bit exploity but hey), and as long as you built in the wire and the pump during the original construction, you can leave it until you can use it. And love it all the same.

Spoiler

Here's the Natural Gas LILI:

LILI_NatGas.thumb.png.61dc14c15a61223e2317d2e8b1c4ba78.png

And here is the simple enough standard automation for it. All the gates set to 2s except the Filler gate, which is set to 10 to allow for the chamber to fill. The automation for the doors under the Weezeworts is a separate automation grid, to stop it from going crazy cold during dormancy.

LILI_NatGas_automation.thumb.png.0cf67b9aa14e6910f8b6c7b85a611628.png

The only potential problem with it that I can see is that the two metal tiles and the tiles under the series of doors might eventually get some overpressure damage... but that could easily be fixed by replacing those with doors I guess. And, I could've used Mechanical airlocks around the pump, to make my life simpler with power and automation.

So this was simple enough, the automation for the door compressor is more or less well-known, and I've seen a similar design on the forums, I've just packed it in a neater-looking cube. And I assume this could be used for any gas geyser of any sorts, as long as 2/4 weezes are enough to keep it cool enough to prevent the equipment damage in the long run.

Apparently I got a bit carried away with my fascination over door compressors and wondered if I can do something similar for a Cool Steam Vent to store compressed water (in my last game my hot water tank was .... very large so I wanted to avoid it). It took a while to get all the details and gates right... And I opened up the debug mode for the first time to give this design a go before killing myself trying to build something that doesn't work in survival. And I made it in the end, but the automation of it turned out to be a monstrosity.

This is the base desing, with the gates numbered (a single whole row is numbered as "2", and similar with "3" as those doors share identical behaviour):

LILI_CoolSteam_numbered.thumb.png.09a0a6fd4bedd05e0a6ff755c64814b6.png

The cooling is completely arbitrary and the upper chamber can be cooled in any preferred way. The default state is like shown on the image, 1 = Open, 2 = Closed, 3 = Open, 4-1..4-7 = Closed. This vacuum separates the upper condensation chamber from the lower collection chamber, so the cooling power doesn't get unnecesarily spent on the already collected water.

The water collects in the empty row just below the Steam Vent, and the two tiles on each side which are in level with the Steam Vent. The Hydro Sensors can be set to any value (around 800kg/tile for best efficiency, as the water doesn't collect equally as fast on the left and the right, it should be a value lower than 1000). When both Hydro sensors read enough water in the tiles, the following triggers (-> between states means "after", while comma between states means "simultaneously"):

1=C --> 2=O,4-1=O,...,4-6=O-->2=C-->3=C-->4-7=O-->4-1=C-->...-->4-7=C-->1=O,3=O (returned to the default state).

What happens during these transitions is:
 

Spoiler

 

1=C - Since there is water in all the tiles below the door 1, when the doors close they will block off all the steam. Water gets trapped between doors 1 and 2

2=O, 4-1=0,...,4-6=O - The doors open to let the water fall in the compressor system. Since the compressor priming chamber consists of 6 doors 4-1 to 4-6, and there are 12 tiles between doors 1 and 2, there will always be enough space for that water in the compressor priming chamber.

2=C --> 3=C - The doors 2 and 3 close in sequence from the top down, to ensure that all the new water gets pushed to the compressor priming chamber. Door 3 needs to be closed for this step to act as a roof for the compressor.

4-7=O-->4-1=C-->...-->4-7=C - This is the "standard" part of the compressor sequence, similar to the basic form used for the gas geysers. When all the water is secure in the compressor priming chamber, the door to the compressed water tank opens, and then the compressor doors start closing left-to-right to push all the water, new+old, back into the compressed water tank.

1=O, 3=O - When all the priming chamber doors are closed again, the doors can return to their default state. Door 1 opens to start collecting water in the condensation chamber again, and door 3 opens to make a vacuum division between the condensation chamber and the compressor again.

 

Now, if this seemed complicated, the automation is just a tiny bit more out there. So, "all" the gates are 2seconds, except the several gates marked on the image below (B = buffer, F=filter, number = duration in seconds; sorry for the bad color choices, I didn't manage to find a legible one):

LILI_CoolSteam_automation_length.thumb.png.5ffc760c7d50f33ba1e77502b8283050.png

So, the details of why specifically those 5 gates need to have a different delay, top to bottom:
 

Spoiler

 

F-30 -- This is because as soon as the water drops from between doors 1 and 2, and through doors 2 and 3 into the compresor priming chamber, the Hydro sensors start reading 0 water pressure, and want to reset the system into the default state to continue collecting condensed water, which must not happen before the whole cycle finishes. 30 seconds seemed to be on the safe side. Unlike the LILI for gasses, this compressor will never work continuously even during the eruption periods.

B-8 -- This gate corresponds to the duration of door 2 being open. I've originally tried it with 2 seconds, but then realized I need to give the water a bit more time to drop through.

F-4 -- To ensure door 3 is fully closed before door 4-8 opens and then all the doors begin closing left-to-right. Also that the doors 4-1 ... 4-6 are fully open.

F-8 -- This delay is partially cosmetic. Without this, doors 4-1 to 4-6 will open and then close one more time (in vacuum) after all the water has been pushed to the compressed water tank. It needs to be longer than the last delay, F-6

F-6 -- This is to ensure that the brief moment while door 3 is closed and door 4-7 just about to open, but still closed (during transition 3=C --> 4-7=O), does not trigger opening door 1. This delay has to be longer than the one for the transition 3=C --> 4-7=O, which is F-4 in order for it to have the desired effect. The second time doors 3 and 4-7 are closed at the same time (after the compression sequence), they will stay so long enough to trigger the system reset, that is opening doors 1 and 3.

 

Now, I am eventually going to try this one out in survival as well (should be doable as long as I catch the Steam Vent during the dormant period), but as you can see the automation got a bit out of hand. Unfortunately, I seem to need every gate in there, no matter how I permute the logic I can't remove a single gate without the need to add one in, and the automation is sticking out of the chamber for 3 tiles to the left, 2 tiles in the bottom and one above the compressed water tank wing.

So, any suggestions for improvements (or space minimization) are more than welcome. If anybody likes this and would like to see how the design simulates, I can also upload either the exported pattern, or the debug savegame where I built it, or both.

Edit: here is the save file to test it out: Potato Test.sav (it's primed with water and should trigger as soon as resumed), and the design file: LILI_CoolSteam.yaml. The desing will paste the whole area including the Steam Vent, walled in in a vacuum room, but one needs to port a dupe into a Hydrogen room to make him plant the Weezeworts, and set the timers on all the gates since those apparently don't get saved.

Link to comment
Share on other sites

this is a very nice setup but in reality you dont need infinite storage. You only need enough storage to avoid running short in badly synchronized dormancy periods. All above that is something that is never going to be used, but is fun if (when?) they patch pressure to be able to break stuff like doors too and your base experiences an extinction level apocalyptic event :>

Link to comment
Share on other sites

Honestly, when big changes like that happen it's best to start a new base under new rules. And that extinction level apocalyptic event seems like a great thing to watch for entertainment *grabs popcorn*.

And - at least that big tank in that old save of mine that I mentioend - the Geyser ended producing much more steam/water than I needed. So every now and again, I'd have to send somebody into the water tank to make it bigger. I guess I could've just ... tried to useit faster, but that was the time they nerfed abysalite and I took a break from ONI for a couple of months :)

Link to comment
Share on other sites

Honestly, you had a system in mind and you realised it accurately. I took the liberty of making a system a bit more compact and modular based on your idea

:bot.thumb.png.ef3e46a5ccbd11d250bc5bc515ad02e3.png

 

So, we assume that the control input is something normally off. Then, at the slightest hint of green on this wire, we trigger our system on. Our system will do excactly this things, it will open all doors except the bottom rightmost one.. Then, whenever the control input becomes red again, it will close the topmost doors.After x second which you set the right buffer gate looking downwards, the bottom ones close, and after x + y sec, the flipflop toggles itself again, closing the vertical doors. 

edit:The buffer gate that is set to 1 second, should acctually be a filter gate set to 30+x+1 sec

Link to comment
Share on other sites

@Arnadath I'll be giving a go to what you posted straight away, tyvm for taking a look.

I'm trying to figure out why you omitted door 1 from my design. I see you've tried it out without an actual geyser (or just filling the area with water would work for testing purposes). The reason I have door 1 in my design (those are the less visible doors one level above neutronium) is that, when the whole compression process begins, I don't accidentally get uncondensed steam in my compressor. Not sure what that would do (probably, given enough cool water in the pressure tank, it would just condense in time), but I didn't want to risk it.

Also I see some of your timers are as low as 1s - I'll test it with water to see if that's actually enough time for the water to pass through all the chambers properly.

I'll also update my original post with the savegame, as I'm not so sure you reproduced the same behavour I have. But I'm definetely testing what you posted.

Link to comment
Share on other sites

5 minutes ago, riwenna said:

@Arnadath I'll be giving a go to what you posted straight away, tyvm for taking a look.

I'm trying to figure out why you omitted door 1 from my design. I see you've tried it out without an actual geyser (or just filling the area with water would work for testing purposes). The reason I have door 1 in my design (those are the less visible doors one level above neutronium) is that, when the whole compression process begins, I don't accidentally get uncondensed steam in my compressor. Not sure what that would do (probably, given enough cool water in the pressure tank, it would just condense in time), but I didn't want to risk it.

Also I see some of your timers are as low as 1s - I'll test it with water to see if that's actually enough time for the water to pass through all the chambers properly.

I'll also update my original post with the savegame, as I'm not so sure you reproduced the same behavour I have. But I'm definetely testing what you posted.

This is a control mechanism , an actuator for other events. You are supposed to keep the rest of your design the same. Also the buffer gate times, are at your discretion

Link to comment
Share on other sites

This whole thing started by me planning to build it in survival, pre-steel if possible :) I feel kinda bad for actually coming up with sth so complicated I felt compelled to try it out in debugger first.

2 minutes ago, Arnadath said:

This is a control mechanism , an actuator for other events. You are supposed to keep the rest of your design the same. Also the buffer gate times, are at your discretion

Yes I figure I can set the timers as it suits me, I'm just still confused as to why you're missing one of the doors (or rather, two of the doors labelled with number 1).

Link to comment
Share on other sites

@ArnadathOkay so I've tried building it, I really did. I'm fairly sure I got something wrong becouse it's not really similar to what I had up there, and besides the whole chunky part (marked with a ?) doesn't simulate into anything useful to me.

doors_example.thumb.png.fe84030ee8035fd8d2157d60c5f2fa9b.png

So, first of all question on where I understood your design wrong regarding the circled part marked with a questionmark: This part is doing absolutely nothing for me at all. The input to this part (output from the left buffer gate up top), is always the same to the input down bottom. I could just as well propagate the buffer gate output downwards, nothing would change (I tried it); cut the circle bit out completely.

Then, another question: how exactly does this circle bit actually manage to propagate it's input? The way I drew it (and I assume I understood you wrong), this bit does nothing at all but it does so in a wonderuflly complicated manner. There's two not gates in a row, and then hooked to a xor with their input... which should make the output of the xor always false as it's always going to have two same signals as input. So, the fact that this whole hot meses with a memory toggle propagates the input must be due to 1-frame delay on all the gates you were mentioning in your other thread?

And then... what actually happens VS what I panned to happen in my design. I've labeled the doors here with A, B, C-1 .. C-7 (I took out the left-most vertical door as that one is supposed to be an always-closed mechanical lock, not automated). Assuming your door A matches my door 2, door B my door 3, and door C-1..C-7 my 4-1..4-7.

What I observe happening from your design.
A) default state = everything closed. But doors B (or 3) should be open in the default state.
B) On input signal T(rue):
A=T, B=T, C-1..C-6=T --(30s later)--> C-7=T
If the T signal lasts on control, door C-7 gets stuck simultaneously open with B, which should never happen.
C) On input signal F(alse):
A=F--(10s)-->B=F--(10s)-->C-1=F,C-7=F--(2s)-->C-2=F--...-->C-6=F
The door C-7 closes as soon as C-1 closes. This would render the compressor pump useless: the idea is for the water to get pushed through the compressor priming chamber (vertical doors) all the way to the right, so the C-7 needs to shortly open after C-1..C-6 afte open and primed with water, and after B closes (to provide a roof for the closing compressor).
D) If I flick the input switch (single pulse F->T->F) - and I can reasonably expect my control input to just be a flicker.
A=T,B=T,C-1..C-6=T,A=F--(10s)-->B=F--(10s)-->C-1=F--(2s)-->C-2=F--..--C-6=F
C-7 remains closed all the time. Also, door A opens and starts closing immediately which would prevent the water from dropping through. Basically, on flickering input, A needs to stay open for at least 6 seconds for the water to pass and fall down to the compressor priming chamber.

If I change the filter gate from 30 seconds to 15 (that is, a duration between the buffer gates in the upper part), I get a slightly different sequence which is not too far from what I'm looking:

A=T,B=T,C-1..C-6=T,A=F--(10s)-->B=F--(5s)-->C-7=T--(5s)-->C-1=F,C-7=F--(2s)-->C-2=F--..--C-6=F

The door A still flickers open and shut. But that's easy to fix in fact (just another buffer gate in front...). Door C-7 now opens, and that happens after door B is closed, which is good, but then it just shuts as soon as C-1 shuts, so no water actually gets compressed as it has nowhere to go (in fact, this setup would delete water). This can be easily enogh resolved by either adding another buffer gate before or after that filler gate as input to C-7 (sum duration as the sum of buffers between C-1 to C-6 + 2s delay); or putting the output of that filter gate and the output of C-6 through and and-gate and a buffer gate with 2s delay. With those modifications, I can achieve the following sequence (assuming I adjusted the timers on all the gates accordingly:

A=T, B=T, C-1=T...C-6=T --(5s)-->A=F--(5s)-->B=F--(5s)-->C-7=T--(5s)-->C-1=F--(2s)-->C-2=F--..-->C-6=F--(2s)-->C-7=F

This is quite close to my original sequence, with two differences:
- why did you forget my doors labeled on my original image with 1? They were difficult to work into the sequence
- the default state for your door B is "closed" (F). This door should, however, be open by default, and only close temporarily so "squish" the water down and then act as a roof while the compressor is compressing.

So, assuming that I label my original door one with X, the sequence I'm in fact looking for (on input pulse; from default state, X=T,A=F,B=T,C1...C7=F, and with my original gate timings, but that's easily adjustable):

X=F--(2s)-->A=T,C1..C6=T--(6s)-->A=F--(2s)-->B=F--(4s)-->C-7=T--(?,nodelay)-->C-1=F--(2s)-->C-2=F--..-->C-6=F--(2s)->C-7=F--(6s)-->X=T,B=T

So after all this analysis... It doesn't seem completely straightforward to modify your system to do what mine does (and add an extra door in the loop). Also, technically, I don't get a pulse input, my "pulse" lasts for as long as it takes for the water to fall down, which includes the time it takes the door to actually fully open, until the Hydro sensor stops reading the required water pressures, which is an undefined number of seconds (2,3,4,5? I left those doors open for 6 just to be sure). But, finally, really, can you please plese explain what you did there with the memory toggle? I'm sure it wasn't an equivalence gate :D and I got you completely wrong on that bit, but I don't even understand how that is producing an equivalence for me. It's late, I'm tired and it's been years since my last course in Digital Logic :D

 

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...