Pipe Flow / LOX-Sour Gas Condensing

[storm6436]

(TL;DR; summary sorta in the middle, before potential solutions)

 So, I've been playing this game off and on for... uh... *counts fingers and toes* since maybe six months or so the Tubular upgrade... I'm one of these guys who spends hundreds of cycles just studying the facilities I design and working out improvements for capacity, efficiency, etc.  I've never actually launched a rocket yet because, well, by the time I get that far, usually there's a content patch and I have to start over.  Not much different from how I play KSP, actually.  Get to Duna and patch shows up.  It's a consequence of limited time, I guess.  My class load during most of the year is pretty brutal, but that's a physics degree for you.

  Anyway, the one thing I'm embarrassed to admit is that I've never managed to wrap my head maintaining proper pipe flow., When I started fiddling with cut-offs, I noticed they had this annoying quality depending on how they were placed where liquid flow would jerk every other tick as the fluid tried to figure out if the cut-off was open or not, leaving you with half-throughput.  I compensated by splitting the cut-off valves off the main line and using bridges to feed them which works pretty darn well for normal every day use. 

 But day before yesterday in the game I'm abandoning, I made a heroic effort to address a problem right before I started setting up my first rocket.  Turns out the map generated the oil biome with a gap in the abyssalite due to POI, exposing a corner directly to magma and until shortly before this point, it had been far enough in the dark section of the map that the effects weren't being calculated..  there's a comedy of errors involving not mousing over a chamber of sour-gas on my way to seal it off with ceramic insulated tiles.  Hilarity ensues and a lucky inadvertent liquid lock from a brave passing slickster saved a bit of the day by cutting the rolling cloud of sour-gas in half, but the half that makes it through is still more than enough to require 70+ reservoirs, which kinda eats into my metal supply.  I kinda want that metal back, so I do some quick thinking and arrive at a dumb conclusion (In hind-sight, dumb only because I don't have space-age materials)  ... I was already running an ethanol cycle and 2 petrol gens to cover peak-power for my multi-tuner cooler,, figured I could use the NG, so I decided to set up my first H2->LOX Sour-gas condenser... and learned a hell of a lot from the experience. 

First lesson  This sort of thing is not conducive to my general "Ah, I'll eyeball it" approach to games.  I've taken statistical mechanics, I understand heat flow, there's no excuse for me to not do back-of-the-napkin math to properly spec out these facilities for both available cooling wattage and radiant pipe lengths.  Post-hoc, having done the math, I'm disappointed in my past self because what followed was entirely predicable and a virtual certainty I should have seen coming. 

Since I eyeballed it, the H2 loop was under powered and initial LOX production was quite slow... and complicated by the fact that I'd missed single chunk of igneous debris in the LOX room machinery clutter.  Oops.  Luckily, the H2 room had enough space to easily shoe-horn a second regulator into it and when my condensation basically came to a halt, I spotted the debris.  I saw how slowly heat was leeching out of the debris and realized it'd be 100+ cycles before it stopped eating my LOX, so... seeing as my dupes are suicidal on a normal day, I decided to indulge them to get that debris out.  All in all, this poorly designed bit ended up working, just working slowly, at about 95 -105 g/s of LOX.  Still, not bad for a first try, I guess.

Second lesson: I no longer have the luxury of not completely understanding ONI's pipe flow mechanics.  Seasoned LOX folks almost certainly know where this is going.  I'd rigged the LOX loop with a few automated by-passes, one covered the temp-controlled feed for the tuner I'd added to my steam chamber, one switch-controlled to toggle the condenser section of the loop, and used the outputs of both those segments  to control a cut-off on the liquid reservoir in the LOX chamber so that if it was too cold to feed the tuner and I wasn't running the condenser, everything would collect in the LOX chamber and stop circulating.  The circulation cut-off worked beautifully.  With the exception of a single incident, the tuner cut-off worked as far as protecting the tuner from freezing the LOX, but I'm fairly certain I know why...it's because of how I'm doing the bridge feeding, which traps a packet in front of the cutoffs.  The trapped packet then warms at about 0.1F/s until either it pops the pipe or gets fed into the aquatuner when it shouldn't have been which then eats the output junction and floods my steam chamber with 10kg of <-350F O2

 Side note: Thankfully my steam chamber design actually makes short work of that if it's idling, since the burst of cold is sufficient at full-idle to force condense all steam directly and leave only O2... and the last phase of my automated SCRAM system kicks in, force-toggles everything off, and begins pumping the offending gas out.  

But... it was about this time that I started doing the back-of-the napkin math I should have started with, comparing specific heats, expected temperature ranges for inputs, etc. and realized that the condenser section I'd built would work... for values of work. I knew it was already going to be slow.  Due to location and space limitations I couldn't easily work around I hadn't included a heat exchanger to pre-chill incoming sour-gas with the NG output ... but the math proved out that it was going to be significantly slower than I expected.  For what I'd built, the only way to make it any faster was to apply more brute force (MOAR BOOSTERS!)  and... well, adding another tuner to the loop like I'd done with the regulators on the H2 wasn't really an option I was willing to take, given I'd already wasted a ton of time and it'd take even longer to rework the tuner segment to allow for temp-determined single/double tuner operation.  I'd already long since worked out how to automate my primary coolant to operate in a 2-pump, 4x0->2x2->1x1->1x0->0 config, so I had an idea how much time that would entail.  And that's before dealing with the additional power load.

TL;DR SUMMARY:  Properly piping LOX loops is kicking me in the face.  I get trapped packets where they shouldn't be trapped because I'm using bridges to feed cutoffs, and I've been using bridges normally because I'm trying to maintain 100% throughput, not 50% due to flow-jerk on cut-offs, and trapped packets for H2O/PH2O isn't a system killer so I've been able to get away with it until now.

Potential piping solutions:   I've googled a fair bit, and I think I might have a solution, but it'll be next weekend before I can actually test anything (yay, class and tons of quantum homework) so do any of you think these proposals might work for 100% flow and proper filtering?  I get the impression that the bypass needs to be the immediate next tile after the temp sensor used to toggle the cutoffs.  Also worth noting, I'm well aware a lot of this gets significantly easier with super-coolant.

Concept 1: 
Pipe layout -  123. 
Flow layout - 1->2->3
Temperature sensor attached to segment 1
cutoff 1 input attached to segment 2, output to separate pipe either up or down. Designated by-pass.
cutoff 2 input attached to segment 3, output to separate pipe either up or down. Designated line-feed. (Normal operation path).
Automation layout: sensor directly to cut-off 1 and a not-gate.  not-gate feeds cut-off 2.

Potential strength:  Eliminates bridges altogether if it works. and saves a fair amount of space

Concept 2:
Basically the same as above,except:  Add two additional pipe segments below 1 and 3 with a bridge forcing output from 3 back to 1, which would require the main feed for pipe 1 to also be bridged to prevent flow confusion. 

Advantage: Packets shouldn't get stuck, period.  Provided I have the temp sensor located properly.
Momentary disadvantage:  Very minor input flow jerk.  Re-inserting the missed packet (presuming the layout can miss a packet) will halt the input flow one pipe-tick.

Concept 3&4:  Same as 1&2 but with bypass/line-feed swapped -- I'm not 100% certain on the timing for cut-offs.  If the cut-offs cycle shut the same tick the offending packet triggers the sensor, then concept 1 might trap a packet on pipe 3 which necessitates using concept 2's layout if I don't redo the piping.  Similarly, this also might shunt a "good" packet into the bypass when it didn't need to be.  Minor concern, but non-zero.  I'd like to get this working exactly right the first time seeing as I've already wasted a *LOT* of time trying to just get the proof of concept up and running.

Anyway, this was a lot to read, even if you took the TL;DR; path, so sorry and thanks for reading this far!  Any ideas which idea would work?  Or if none of them would, any suggestions for a layout that would?

Addendum:

 I'll point out that when I conceptualized this whole thing, I referred to it as the "Schroedinger's Idiot Box" when talking to my wife about what I was working on, seeing as in real life the concept of cooling a fuel with its own oxidizer is... a hilariously unwise choice... and basically, to create a set-up like this in real life, you're both an idiot and not an idiot at the same time, but you won't find out which until you press the button and let it run.  Thank God they don't model fire and explosions in this game.

[ruhrohraggy]

Inb4 : Pictures plz.

As detailed as the write-up was...Pictures speak a thousand words. Have a hard time following some of it. There's a lot of fluff in there. I'm guilty of the same thing sometimes...I understand.

Basic pictures with like, arrows and stuff would be much more useful. Though to tack those on to the giant brick would probably be even more daunting.

As an aside, I've come to this conclusion : Using hard math to accurately solve real-world problems works and is great. Using hard math to accurately solve and predict things in ONI is a crapshoot at best, most of the time...

As for making Lox or lh2 without the use of supercoolant...for the lulz I guess? The only surefire way I've gone about that is via thermo regs and h2, so I can only assume that's what you're trying to do.

Have done it before...it's neat I guess...but that was before supercoolant. Now that time putsing around with inferior cooling options is spent getting my hands on 1000kg of supercoolant, which trivializes and expedites all of my desired cooling needs.

And if I understand your problem correctly (which I probably don't but I'm not reading that again), my usual method to overcoming potentially trapped super-cooled fluids, is to setup an insulated reservoir for them to return to, and always give them a path to circulate back to that reservoir if they were to otherwise sit trapped in the pipe. This is pertinent when you're doing things like...fueling a rocket. I also make sure to pipe super-cold things through a vacuum if possible, using high thermally reactive materials (radiant wolf or aluminum piping), so the pipe can get cold fast without completely breaking.

To me this seems like a matter of : "Do I go through with this for the challenge? Or should I opt for a more viable solution to what I'm trying to do".

I went for the mech-engie degree though...So I usually opt for the latter.

[storm6436]

 

1 hour ago, ruhrohraggy said:

*snip*

Yeah, I'll have to find some time once I finish my Quantum homework to drop into debug, do some screenshots and photoshop/MS Paint them up for clarity.

 As for the hard math, there's a reason why I was keeping it to basic algebra and not throwing calc/DiffEQ at it    Basically I was abusing specific heats, thermal conductivity,expected temperatures, flow rate, etc to resolve everything to "I have X watts of cooling on the loop, but Y number of radiant pipes which means they can apply Z watts of cooling at maximum temp differential.  X<Z=bad.  There's a bit more to it in terms of optimization that I pulled myself away from pondering... I generally leave optimization for after I make the darn thing work right the first time. Hence why I haven't built a rocket yet, as per the first few paragraphs of the OP.  Otherwise, I'd have supercoolant and be enjoying the ~8x specific heat and much wider liquid phase temperature range.  There's literally no reason to do what I was doing unless you're a masochist or you have no other choice at the moment.  Given the sour gas apocalypse that was rolling across the oil biome, my case was the latter as the magma breach had converted an entire oil pocket, one of the "Dig near me and I'll pop" ones, completely into sour gas... and I didn't realize that's what it was until it was too late.

 In terms of the reservoir bit, I came to the same conclusion you did and have sufficient storage capacity in the all my cooling loops (not just these) to where if I need to shut things down, circulation stops as all free packet returns to the reservoir.

 Let me try to rephrase the problem since there was a fair bit of fluff.  I noticed a while ago that if I had a main pipe and I made a 1-tile branch with a cut-off whose input was on that branch, the main pipe flow would jerk because every tick the arriving fluid would pause to see if the cut-off was open... so you end up with a gap between every packet that proceeds down the main after that, cutting your throughput in half.  My solution was to use a bridge on that one tile branch that lead to the cut-off... the main flow doesn't pause with bridges for some reason.  This works just fine when you're pumping anything you're not worried about phase changes or temp sorting on.   Come to think of it, I haven't tested to see if this is still the case in quite a while.  I'll be more than a little embarrassed if they fixed this and I didn't notice.

The bridge-to-cutoff doesn't work for my LOX loop because you end up with a packet trapped on the far side of the bridge that can't go through that cut-off.  And since I'm using cut-offs based on temperature sorting, that setup goes from "Meh, this isn't working" to "Wow, this is trash.",   Hence my proposed solutions simplified to a 3-tile length pipe , cut-off inputs on the last 2 tiles, temp sensor on the first tile.  The main differences between the four solutions boiled down to which cut-off was being used as the bypass and whether or not I needed to add an extra bit of pipe and a bridge to loop missed output from the last cut-off back to the front of the line or directly into the other cutoff's input. 

Basically, what I'm trying to ensure is:
1. 100% throughput (or as close to it as possible without hitting 50%)
2. Proper temperature sorting so I don't drop 10kg of frozen oxygen into my steam chamber.
3. Minimal amount of space/materials taken up by the assembly.

[storm6436]

Okay so I was going to go set-up sandbox mode and build examples of what I was talking about to take screenshots... and in the process of doing so I facepalmed hard enough I'm sure I lost a few brain cells. I need to be more careful, I don't have that many to start with   Skipping the details of why I facepalmed that hard, I realized that if I could set stuff up for screenshots, I could have just tested all this crap myself instead of bothering you guys in the first place.  Sorry for making brains hurt.  If it helps any, mine does too now.  So I spent a half hour testing instead of taking screenshots and came to one immediate conclusion:

Either Klei *did* patch out the flow-rate issue  that I was "working" around with my bridge-pocalypse, or it's maybe an issue that shows up only once the system is under a lot of computational stress and it starts slipping calculations across frames.  I'm hoping more the "Fixed!" and less the "Your computer is a potato."  Only other possibility that comes to mind is that I was placing them wrong originally and running into flow priority games.  Either way, the issue never showed up on any of the loops I was testing, so I'm assuming patch/potato are the most likely explanations.

I started with something simple so I didn't have to mouse over everything.  I figured element sorting was going to be functionally identical to temp sorting, so I slapped H2O and PH2O sources together and merged them to a single pipe so they'd be alternating past that point.

After a few iterations, I figured classifying the fail-states would help identify root causes, and once that was done, a solution that hit them all would be soon to follow.  So, the fail states I noted?
1. cut the power to the cut-offs, everything goes to hell on restart .  Dogs and cats living together...
2. Downstream pipe (either one) backs up, same as above.
3. Kill one feed long enough for it to clear out of the line, and restart it?  Which pipe gets used for what element swapped.

I realized pretty quickly that problems 1&3 were a basically a timing issue, and that #2 meant using a loop similar to my suggestion in Concept 3&4 in my original post..   Three iterations later, I decided to start over from basics... just pulling one element out of a flow loop... which my redesign did beautifully.  But... the loop isn't optional for temp sorting, so it did me no good to pull out one without being able to direct the other... but every time I added a second cut-off, I'd reintroduce problems 1&3 again. 

After another few iterations, I suspected the problem was because sensors trigger the game tick a packet starts to enter the cell,  This means the sensor you're using has to be right in front of the cut-off... and after another iteration or two it kinda hit me: you really can't use a not-gate to toggle between the two cutoffs, no matter how much you want to.  The sensor's output is only valid for one pipe tick (Time it takes the liquid to move one square) ... so with 1 sensor, your second cut-off is getting data for packets 1 tick farther away than the first cutoff... for proper operation, that data needs to be 1 tick old, not 2.  

I briefly pondered the idea of some very short-acting filter/buffer gates to basically delay that signal to the right moment, but it occurred to me that if the power failed, this might not work on restart, provided you could get the delay timing precise enough in the first place.

So I rebuilt it using 1 sensor per cut-off, let it run a bit, and then started throwing faults into the system for failure analysis... and... it just worked.  Happy, I googled some more to see if anyone had a better design in terms of space and came across a reddit thread where I'd basically recreated what the reddit user posted about.

 I figure as part of my mea culpa for wasting everyone's time, I'd drop the link here so anyone who stumbles across this thread at least gets some useful information out of it at the end:  Reddit thread

[Lifegrow]

No disrespect intended, tl;dr was not meant for people like you. You tricked me. Repeatedly. Damnit.

Pics or gtfo  

[storm6436]

Reddit link at the post above yours has a variation of what I went with.  Only difference is bridge placement/loop length.

[Lifegrow]

Ahhh I understand now. You needed a looping filter line.

If it makes you feel any better, I did this mistake live on stream tonight...

Petroleum tank broke -> pipe backed up -> pumped petroleum into my over-pressurised oil tank (containing half the asteroids oil in one juicy room might I add) -> around an hour looking at it, scratching my beard  

Glad you got it sorted nonetheless.

[ruhrohraggy]

I do want to point out (though you may already know, other's may not)

A not gate is still pretty useful for diverting all other fluids (or gases if using a gas system) *but* the one you are interested in. Basically reversing the typical use of the shutoff / sensor combination. The latency is low enough to not cause any problems.

This flips the typical drawback of the shutoff valve, such that, if your desired element backs up, everything gets diverted. This means you will not have un-wanted material flowing by your shutoff. On the other hand, your desired material will be diverted as well, but the drawback is now more easily solve-able with a loop.

I used this mechanic in my SPOM design, and it was pretty handy.

See example :

 

Spoiler

 

 

Spoiler

 

[storm6436]

Yeah, that's one of the things I confirmed with my testing.  It isn't the latency of the individual gates that really gets you, it's the distance from sensor to cut-off.  It does you no good to know that there's a PH2O packet 2 blocks away from the cut-off it's supposed to go through if the next packet is water that instantly closes the PH2O cutoff and opens the water one.   You'll screen the water correctly and the PH2O will continue down the loop, provided you have one, otherwise it'll sit there trapped until the Ph2O cutoff opens again.  Sure it'll be filtered correctly in this case, but it'll be filtered correctly on accident.    That issue is the primary cause of problems #1/#3 in my "Doh, I'm a moron" post.

[TLW]

53 minutes ago, ruhrohraggy said:

The latency is low enough to not cause any problems.

Ha. Ha. Ha.

...But seriously, this will occasionally randomly break, generally when you're not looking at it.

[storm6436]

Isn't that how it always works though?  It's like any system full of quantum objects... the interesting stuff always happens when you're not looking, even when you are looking..

[ruhrohraggy]

28 minutes ago, TLW said:

Ha. Ha. Ha.

...But seriously, this will occasionally randomly break, generally when you're not looking at it.

This was installed on cycle 50 and employs a not-gate gas ejector, It's caused me 0 issues. It was designed that way. Nothing involved in it's operating process will break it. The only thing that stops this thing from working not having water...

 

Spoiler

 

 

I would wager 99% of things in ONI don't randomly break. There is a reason they break you just have to dig deep enough.

If you completely understand where the drawbacks are and design your system accordingly, then your things won't "randomly" break.

[storm6436]

On 8/27/2019 at 12:30 AM, ruhrohraggy said:

This was installed on cycle 50 and employs a not-gate gas ejector, It's caused me 0 issues. It was designed that way. Nothing involved in it's operating process will break it. The only thing that stops this thing from working not having water...

 

  Reveal hidden contents

 

 

I would wager 99% of things in ONI don't randomly break. There is a reason they break you just have to dig deep enough.

If you completely understand where the drawbacks are and design your system accordingly, then your things won't "randomly" break.

 Yep... and being OCD enough (or otherwise motivated) to do that deep dive is where most folks fall short.  I should post a screenshot of my automated hatch killer.  It isn't impressive in the regard that it's an automated drowning machine.  Hell, it might not be impressive to anyone else, but I fit everything but the automation in a a 7wx5h space with 6 tiles (3hx2w) taken out in the lower left hand corner.  And the kludges I made to get it shoehorned in... like the top row of the kill chamber? All but one tile are mesh tiles that serve as the floor for the apothecary room above the chamber.  The one non-mesh tile is the water vent   Stores precisely the amount of water necessary to drown a hatch and two air tiles on the sides ensure the water spreads out evenly so there's no place for the hatch to go.

 Honestly, the automation and the things I had to route around is what makes it impressive to me... Deliver hatch. Leave room.  Hatch dies. Only thing I'm missing is a sweeper arm to grab the meat. 

Normal operation: Due to space necessity, the kill floor is flush with the floor outside, so when trigger conditions (critter AND no dupe in room) are met for I think about a half second, it fires sys_init. Sys_init activates the Sys_Control memory gate which passes sys_active signal. Using signal propagation tricks,  sys_active immediately shuts/locks the door, and after a small delay, activates the water hatch circuit.  Through a series of buffers, filters, and a few gates, w_hatch opens the hatch for 9(ish?) seconds and then toggles it closed.  Under normal operation, that hatch cannot open again until the cycle resets.  After a certain delay, sys_active finally activates the pump, which is delayed enough that the hatch drowns before the pump removes enough water to stop death.  During normal operation, the critter sensor output is used along with outputs from a water element sensor on the pump pipe and the sys_active signal to determine cycle status via two gates. When the pipe and critter sensors are off but sys_init is on, this passes sys_reset. On reset, the door unlocks and the room is ready for the next use.
 
 That sounds pretty simple... but other features got tacked on to deal with edge cases. 

Abnormal operation:  The Master Timing Circuit samples sys_active.  If sys_active stays on longer than the normal time it takes for a kill-cycle, from a programmer's perspective it throws an exception by passing sys_err signal.  Sys_err does two things, it force resets the sys_control gate and holds the sys_active signal to on.  The assumption is that something has gone wrong that requires attention, so we keep the front door locked and the pump running until dry so no matter what happened, absolutely nothing escapes the chamber. (Side note: due to paranoia, I also put a water level sensor that prevents the front door from opening at all if there's more than 1-2kg in the next tile so the door part might be a little redundant)  Resetting sys_err requires manual intervention, but that's actually easier than you think.  Via XOR/filter/buffer logic, the switch resets sys_err on switch toggle, not switch on or off.   Minor time savings, I guess, but I'm lazy.

A second switch can be used to force the water gate to open (not cycle) - useful if the error state means the hatch survived somehow. Haven't had to use this in quite a while. The third switch is mostly vestigial, but it can also be used to hold sys_active to on.  Between those three switches, the entire process can be manually manipulated without entering the room. 

 There are some signal propagation delays built into the sys_init signal precisely because the configuration of gates and sensors used has a chance to activate the initial game load when the input states, etc flip flop during map initiation.   Those delays are just long enough to eat any errant signals.

The one edge case I haven't worked around completely yet? 2nd dupe arrives with 2nd hatch right when the door is supposed to lock? Door can't close, so there's a delay built into signal propagation that barely allows a moving dupe time to get out while still trapping the hatches. If he hesitates at all, he's staying inside until the cycle finishes. Thankfully there's a ladder in the one open space possible so no matter what silliness the water gets up to, he won't drown. This isn't a problem if it's early enough in the cycle... but late enough and your dupe is going drop some polluted water and now we have food poisoning.  Minor gripe, I guess, but I don't like leaving vectors, so I've considered adding a second, one-way hatch on top of the front door to allow for immediate escape/ I'd have to move a significant amount of automation to make that possible so it hasn't been done yet. 

A good chunk of all the logic tacked onto that was to catch error states so I could figure out what happened... and given that the MTC hasn't thrown a sys_err but maybe twice in the last 300 cycles, and those two times were the reason above... I'd say I've found all the different ways it can break (or at least the 99% solution) *shrug*   So yeah, you're correct, if you deep-dive you realize nothing ever really breaks "on accident" ... even when it's the game state initializing it's random init noise, not an accident.

 As an aside, while building/troubleshooting this was a lot of fun and I certainly learned a hell of a lot about building use-specific circuits in ONI, my next iteration will *not* be in this tiny-ass box.  Completing the challenge once is sufficient enough... though the second version of this will eat a fair bit more power because I'm going to mesh-tile the killbox so I can deal with literally any creature, not just hatches. To speed things along, this will have two reservoirs and dupe access from above via ladder into the killbox and said killbox will be *only* the drop-off point. I won't need to worry about automating the entrance hatch at all then... If the concept works the way I'm hoping it will, the top reservoir will hold enough water for two uses, so timing the door(s) will be important... but draining it?  Simple. The floor is automated hatches.  The moment the critter is dead, dump the current water into the second reservoir that I can service with multiple pumps... thus not only will this kill anything, it's duty cycle and repetition time will be much shorter.  Probably looking at a two-floor (9-10 tile, counting walls) sized unit, maybe a little taller

Added later:

 Things are a bit crowded, so sorry...

 As we can see, my memory of the dimensions was off a smidge.  This is on game_init so signals are a bit loopy.  Also, one of those sys_err events happened a few cycles before this and things backed up before I noticed, as is plainly obvious by the extra hatches wandering around the medbay and the extra guy up top.  Thankfully the medbay guys are self-solving and reguire no intervention... the moment that door opens they usually b-line for the meat and doom themselves.  Conveniently they start drowning before they can eat anything.

 

 

Added even more later: 

 On second thought, I went back to take a screenshot of the system under normal operation so the signal paths were easier to see, and it became immediately obvious once the game-init shuffle finished that, no, what I thought was going on was not in fact what was going on.   I haven't played this map in a while  

 So yes, the back-up did happen, but what was going on in the original screenshots (deleted the automation layer to replace it with the new one below) is... an edge case I haven't encountered and can't immediately explain. LOL.  There's nothing alive in the chamber so it should be emptying.  Maybe the game didn't save sys_control's active state?  Or maybe game_init static triggered a reset?  Not sure.  Either way, the new screen shot shows the utility of the third switch (highlighted in the upper left corner.)

 Upper right hand corner you can see the on-toggle trigger.  Both AND gates  were necessary for signal isolation in an earlier version, but I forgot to take the right one out when I simplified the rest of the circuit.  Connecting the not gate's output directly to the output of the filter to the right accomplishes the same thing.