100% uptime VacNuke Automation via Project Red/AE2 cell swapping, improved over GTNH wiki

[analog grove]

Tier: EV+.
Version: 2.8+

The GTNH wiki AE2 vacnuke circuit has a truly alarming warning on it, as it has a 5% chance of simply exploding on coolant swap, depending on reactor tick timing. This is obviously unacceptable, so I fixed it. (Notes: Reactor sync ON, set 14 coolant/40 fuel to the total coolant/fuel used for all connected reactors. The coolant swap threshold must be raised to 50% for use with 1080k Space and The Core, or 75% for 540k, due to their short lifespan. The 1s "late swap" timer MUST be set to a whole number of seconds, at most 1s for The Core with non-neutronium coolant)

Final caveat: Lag tests did not cause explosions, but severe, consistent lag may affect level emitter timing (see credits). Use warded glass, send cables around corners to prevent blast leakage, and take backups.

Start with the design from the wiki (see credits), but only place red alloy wires and buffer gates directly attached to AE components. Do NOT place the timer pointing into the coolant subnet ME IO port--that causes the wiki version to explode. (I have the coolant subnet inwards by 1 block. This is cosmetic.)

Copy the circuit here, or the slightly improved version here (removing an unneeded connection) #1438418690235170948 message, which has 2 (potentially wireless) redstone inputs and 1 wireless redstone output. It also has 6 level emitters as inputs, 4 from the reactor subnet and 1 from each of the other subnets, as labelled in the image--use fuzzy cards and set the damage thresholds as appropriate.

Tick timing info credit to Ivelieu: https://docs.google.com/document/d/1Nv8h9H5WUGov727fnXL8A1sAbu37z6uvKkF2TSHsH7o/edit?pli=1&tab=t.0#heading=h.87r6u4hgrtoq

Base vacnuke automation guide credit to GTNH wiki: https://wiki.gtnewhorizons.com/wiki/Vacuum_Reactor#Method_2:_Applied_Energistics

Additional technical information cut off by character limit:

The way this circuit works without causing an explosion on coolant swap, well... its complicated. Basically, level emitters have a reliable, 41 or 42 tick delay between a change occuring in an inventory viewed by storage bus and the redstone level changing. This effectively lets you "read" the reactor tick, so as to avoid swapping coolant on that tick (which would cause an explosion). The delay in the circuit leading to the coolant swap is sufficiently small (~4t) that the total delay will place it squarely between reactor ticks, and the use of the timer-rslatch pairs prevent rapid input flipping from causing it to overlap with a previously triggered fuel swap so as to not scramble the contents of the reactor(s).

The 30s delay before shutting down the reactor is to handle cases when multiple coolants fail in rapid succession but not simultaneously, as there is no need to cause downtime for that if each swap was handled properly--if the delay is reduced to 3s, it will still work, but if two swaps are triggered within a few seconds of each other they will cause downtime. At 4s, almost all downtime is avoided as two swaps would need to be requested with precise timing, or three swaps would need to nearly coincide, and so on.

Note that under some conditions, the second delay circuit (timer-rslatch combination) will be bypassed. This is either when the reactor AE network has shut down for some reason, or if the first delay circuit has completed its delay. The AE shutdown should be obvious, but note that the coolant swap(s) allowed during a reactor shutdown for non-reactor-related causes (full LSC, damaged vacuum freezer, insufficient fresh coolant) may not be safely synchronized with the reactor tick, thus the reactor must be shut down for that swap. When coming back up, of course, the coolant has already been swapped and there is no timing sensitivity.

[analog grove]

@plush sequoia This obviously isn't formatted right for the wiki yet, but I would believe that the main design is a clear improvement over the current "5% chance of just going 💥" version. Not really sure of the procedure for requesting that actual substantive changes go on the wiki, so I'm just pinging you instead, sorry.

Let me know if there is something you need from me for that, or if I should just leave off here.

[plush sequoia]

Pinging me is fine!

One thing I will say is that a whole RS latch circuit is not necessary with nukes. The intent is to not rapidly flip states but thats much more easily achieved by increasing the tick rate of the energy detector cover on the LSC

Otherwise I think I understand the idea and it's interesting, but Ill have to read into it more once Im home from work

[analog grove]

yeah the latch circuit is not to prevent flipping the nuke on and off, its specifically to prevent triggering a coolant swap while the previous coolant swap is still swapping fuel

because that would mix up the contents of the reactors

and the second latch is just to maximize uptime, for no reason other than to say "100% uptime"--otherwise it shuts down while the level emitter is trying to figure out if the coolant has been swapped yet

[plush sequoia]

Does this scale well? I can imagine having a bunch of nukes the level emitter is going to trigger all the time

[analog grove]

i... have not tested that. but it should work up to a reasonable amount, as long as its not triggering a swap more than about once per 5s (or if the reactors are synchronized, which they would remain if they started that way) it shouldn't need to shut anything down ever--it would take 30s of continuous swapping before the reactor shut off "erroneously"

although it'll need acceleration cards with larger numbers of rods and coolant to move at once ofc

i could test with the core, it says min coolant lifetime (1080k space) is 11s, so i'd have to change the second latch timer to 3 seconds, and see what the uptime was (it'll force a large number of coolant swaps very rapidly i presume)

Certainly if all the nukes are synchronized then the level emitter will trigger exactly as often as it would on 1--they all wear out coolant at the same rate(s) so each swap will just do 20 coolants instead of 2

[analog grove]

If the power signal was flickering constantly without the timed latch between it and the reactor, it could trigger a coolant swap that would land on the reactor tick (which should have been safe as it disables the reactor) but then also turn on the reactor (causing an explosion)

Which is why the latches are there

Although I guess turning off the reactor doesn't have to cause a coolant swap, I could change that...

[plush sequoia]

The power signal won't flicker constantly if the tick rate is set to like 10s is what I was trying to say, then it only changes states every 10s

[analog grove]

Ah yeah

[plush sequoia]

And even in the same nuke coolant cells are going to decay at different rates. Some have four rods around them, some have three, and others have two. Add say 3 more nukes and there's a lot of coolant reaching under 25% constantly

[analog grove]

Yeah but in 10 nukes with the same design the cells in the same places in diifferent nukes will all swap together

But without synchronizing them, it still only takes one reactor tick with all >25% coolant per 30s to keep everything running

With a minimum lifespan of what, ~300s for mox? That's pretty likely to never hit even up to 4-6 reactors (7 coolant consumption rates due to mirror symmetry, so a swap is requested every 7-10s on average, which will likely not trigger a shutdown). And after that you're probably building 4 or 8 at a time, all of which are synced together because they all started together

[plush sequoia]

True. I'm just thinking of like the average player having say 2 nukes then they want to add 2 more to expand their power. Sounds like they'd have to replace ALL coolant cells everytime they expand to properly sync their percentages. Not a huge issue

[analog grove]

Eh, maybe, maybe not. I'll see what the limit is, I can build like 8 and deliberately desync everything

[plush sequoia]

yeah im just brainstorming. I tested all three designs on the wiki with multiple nukes and for at least 72 hours, cause they're finicky and really annoying and wanted to make sure they were fool proof

[analog grove]

That 30s time can also be extended to up to 80s (design dependent) without impacting safety

Yeah I got the 72 hour test done at least

[plush sequoia]

thats good

[analog grove]

It's been running and not exploded except the one time I set the coolant to replace at 0% instead of 25%

Which obviously doesn't work

Apparently it's hard to make a lag machine though, I wanted to test with TPS dropping in case that affected level emitter delays, they seem very consistent though (41-42 ticks every time)

[analog grove]

yeah even with this mess going on in the reactors (10x, severely desyncronized, no acceleration cards) its not had to turn off yet, the 30s shutdown timer hasn't even reached 10s as far as i have seen. I'll leave em on for a few days once i make a lag machine that can raise tick time to ~55-60mspt (someone suggested observers)

[plush sequoia]

Nice, that's good to hear

Also this is hilarious whoever did this

I know you mention that the 30s doesnt work for the core, but realistically there shouldnt exactly be problems and it could just swap continuously? Could it work if you just take that out?

[analog grove]

the 30s delay is an "additional safety" buffer, so in theory even if its longer than the burn time of a coolant it should be fine--but that means that if you don't have enough acceleration cards to get hot coolant out, it will explode instead of shutting down, currently even if your vac freezer is too small for the reactor setup, it should shut down safely (and restart when it catches up)

If the delay on the 30s is set to <4s, it shuts down too often (on 2 consecutive swaps on adjacent reactor ticks, for instance), and if the core has 14 coolants that last as little as 11 seconds each, you would either have to accept some (probably nontrivial, maybe 10-20% or more) downtime by setting the timer low enough to be safe or accept the risk of explosion if your vacuum freezer falls behind. You can set the first timer separately, though, so that only say 2s without vacuum freezer enabled causes immediate shutdown--that won't affect coolant swap shutdowns

[plush sequoia]

wait is this not 100% uptime design?

[analog grove]

it is with the 30s timer set (as it is currently, for mox)

it will not be if you have to reduce the timer to 4-5 seconds or less

a single swap takes ~2.5 seconds to completely propogate through the circuit (because of the level emitters) and if two swaps arrive back to back, AND you change the 30s timer to 3s (for e.g. core 1080k sp safety) it will shut down.

with 30s on the timer it doesn't shut down unless at least 15 separate swaps happen evenly spaced over a 30s time span

but, you can run the core with the long timer, it just reduces safety, because if the coolant extraction falls behind, it won't detect it and shut down

If you build your vac freezer correctly and use "enough" acceleration cards it shouldn't explode regardless (will test after lag test)

[plush sequoia]

Okay I see, probably gotta build it myself to truly understand it

[analog grove]

yeah, i found the timer-latch entirely by accident and still barely understand it, and its a key component to let through off->on transitions in one redstone tick while delaying on->off transitions by the timer, unlike a repeater which delays all transitions

[analog grove]

ok, it does NOT work with 1080k space and The Core at a 25% threshold for coolant swap, 1080k space burns on the 8th reactor tick after being loaded (in the central locations), which does not give enough time between <25% and swapping (level emitters have a delay). For the core, the threshold would need to be set to 50% at minimum, possibly increasing VF demand, or you would need the 1G Neutronium heat sinks.

[analog grove]

it does work at 50% with 1080k space and The Core (one reactor), the LuV MVF does not seem to be a bottleneck but i'd prefer to do the math... and I wouldn't trust it without 1G neuts for more reactors

[analog grove]

Short video of The Core operating with 540k Space coolant, no fluxed electrum needed, 1A LuV MVF (75% replacement threshold, not 25%)

It appears to just be looping reactor configuration now, at least with the coolants, so it shouldn't ever have an issue (nice thing with the core is it burns its coolant so fast that every possible configuration is covered in ~60s)

[analog grove]

its still there

and the shutdown counter is still at 0, even with 540k space

i would not trust this without a named backup with more than one The Core/540k nuke though (unless the coolant at minimum is synced), it swaps very frequently

and the LuV MVF is absolutely necessary, its frequently at 64 parallels (all that 1A LuV can support on this recipe i think)

...maybe not actually, it seems to be doing an imperfect OC so its wasting half its capacity--yeah 1 IV hatch into the MVF is working just fine, although that's running 100+ parallels all the time at 2A IV with no OC so that's as far as it'll go

[analog grove]

There is an unnecessary connection in the original image, highlighted here in blue. It can be severed without impacting safety by using a screwdriver to disconnect the appropriate and gate.

[opal lion]

What the fuck is this spaghetti thing

[analog grove]

i mean

redstone

it works

although in no universe is it pretty tbf

[opal lion]

SFM is your biggest enemy

[analog grove]

yeah... i felt like playing logic puzzler and don't want to make the SFM controller

so

spent a couple days fixing the wiki circuit

which, believe it or not, is worse (its not spaghetti, but it does have a significant chance to 💥)

[tidal ivy]

SFM: look what they need to mimic a fraction of our power

[plush sequoia]

Well I wouldnt say significant chance to explode, as it stands you just need to hit the 95% chance that the swap tick doesn't align with the reactor tick and then you're good

[analog grove]

Yeah but that is reset every time the reactor is shut down because that also pauses the coolant swap timer (re-randonizing the swap timer vs the reactor tick)

Iirc from testing, each time the reactor does a cold start (assuming that start is at a random time), you have a 5% chance of having it disappear

Although I guess the LSC 10s cover timing should only change on server restart