Frustrated with bunker doors not being consistent (Vanilla)

[Sleepingbag]

I have a set up inspired by Francis John's method of keeping the surface clear for solar panels, it functions perfectly until it doesn't. Occasionally I will receive the buildings broken notification and check on my surface defences to find several things damaged and overheating due to massive amounts of regolith having been deposited on my robo-miners. This interferes with my cooling loop and means I am wasting resources repairing these things every 50 or so cycles. I have a network of 5 scanners which should be detecting any showers 166s to 200s beforehand and a buffer gate that waits 120s to close the doors before the showers start, Since bunker doors take 44 seconds to close they should in theory close just before the earliest possible shower.

If anyone has any clue as to why this might be happening I would greatly appreciate the help. I have attached screenshots of my setup.

[JRup]

FJ's setup relies on a maximum of 2 space scanners. The reason for this is mostly timing and consistency.

Of particular importance is the scanner's behavior once bunker doors are closed above them:

• A. Their scanning capabilities are lost which means the actual signal telling whether a storm is coming is lost as well. That is, until
• B. the meteor storm has pretty much arrived, then the signal is always consistent until the storm ends.

Having more than 2 scanners will force you to "play" with timings and other funny shenanigans that happen with scenario A. If you're already using 5 scanners in your build I could recommend building some more and going for the "200s" scan range, that would help with the randomness of the range you're using at the moment. More automation will be needed to properly take care of that, though.

Two scanners will give enough warning time for the bunker doors to be closed right before the meteor shower arrives. This ensures part B of the scanner behavior will be available to you without the hassle from "A".

In case of needing a refresher, all of the above is explained in his old vids regarding managing the space biome.

The new ballistic options that are in beta at the moment might open up some new build opportunities that might provide some interesting arrangements. I'm not able to test that at the moment, though.

[Sleepingbag]

I did notice after watching it for a while that it tended to be a case of multiple meteor storms in a row that would overwhelm it.

I did some research into the timings behind meteor showers and there's supposed to be a minimum 300s period of calm, 39s for the doors to open, then the robo-miners have to clear it all away. I'm unsure as to how long that takes but I will try adding a 6th to complete the scan quality.

I have covered the surface in solar panels and would like to achieve the maximum amount of uptime possible without having the doors close unnecessarily early which is why I have adapted the design.

Just rewatched the old vid, I guess I'll just trial the system with 6 for now and if issues still occur I'll be forced to switch down to 2. Thank you for your help with this JRup.

[MinhPham]

It's not the bunker doors inconsistent , instead the duration of meteor showers are inconsistent, it might stop for a couple seconds (like 20, 30 or whatever) and start again instead a longer calm time (which is 300s i assume?), which surely will mess up the scanner automations, it's not the same meteor as before the SpaceOut things.

[Sleepingbag]

15 hours ago, MinhPham said:

it's not the same meteor as before the SpaceOut things.

I do own the DLC but it is not active on this save.

The ONI Wiki has information about the shower seasons. I was basing my assumptions off of this.

[MinhPham]

The information on the "wiki" is quite old, these meteor things was before 2020 and didn't get updated since then.

There are fewer meteors back then but after the mergedown i see more and more meteors. I did not inspect their code to see exactly the duration of each events, but as a player i just feel the difference, there are more time that the bunkers are closing, and they have more chances to break up the bunker defense, sometimes the bunker doors are in opening process but the meteors started again

[Sleepingbag]

I believe I have fixed the issue with a bit more automation. I have run it for a few hundred more cycles and have encountered no issues bar an occasional solo meteorite that goes undetected by my Scanners.

I added in an "if showers are detected soon after the doors have opened, shut them immediately" clause of sorts.

A: This is the basic automation for closing the doors when meteors are detected, doors take 39s to close and 44s to open when powered. This means (if you have a perfect scanner network) you can set the Buffer to 160s and the doors should close just before the meteor showers starts. I have mine set to 155s to be safe.

B: This is Edge Detection which is explained on the ONI Wiki guide for Automation. When meteors are detected the right side turns red due to the NOT gate, and the Buffer is activated. The output of the AND gate remains off. Once the meteor shower is over, the input signal once again turns red and the right side flips to green, with the Buffer set to 1s, the AND gate activates for a second thus passing a pulse singal on to C.

C:This is the second stage of Edge Detection. While the 200s Buffer activated by B is on, if the scanners detect a meteor shower within this time the AND gate activates and passes the signal on, otherwise no change occurs. The end Buffer gate is simply to maintain the signal until A activates after the original 160s.

 

The two not gates are to prevent signals mixing. The Filter gate (5s) is to prevent the Scanners from accidentally activating the circuit because I have all but one of my Scanners set to turn off during meteor showers to conserve power and when they turn back on they still have the detection signal for a second.

 

In Summary, A Buffer 155s, B Buffer 1s, C bottom Buffer is 200s, C top Buffer is 200s, C Filter is 5s.

The Switch is so I can close the doors manually if needed but when off it won't interfere with the signals. (:

[Alex_D]

I guess lots of problems arise if we want to keep the bunker doors open until the last moment before the first meteors hit. I found myself not needing this, I don't rely on solar power that much, in fact I'd rather have a steam box drawing power from the debris heat.

Instead I have, like I suppose many others, an array of four to six scanners connected to a single automation wire searching for meteors. It only takes one scanner to send a green signal and thus trigger alarms and initiate the doors closing.

The inconsistency I found myself annoying is when a rocket is returning and the doors just began to close because a meteor. My automation detects the returning rocket and order the doors silos to open but I believe they don't start to open until they have fully closed. I lost a few silo bunker doors to a returning rocket as the rocket wasn't detected on time.

[Sleepingbag]

Most of my power comes from the surface solar but I have a sour gas boiler that can power my entire base during solar downtime/meteors. I am working on sorting out a system to collect all the debris to take the heat as power in a steam box too and also give me usable regolith to use instead of sand. In effect I'm trying to achieve full sustainability or as close to it as possible. Solar isn't necessary I just enjoy it.

In terms of rockets I have designated the left side of my base as one massive rocket silo. No solar panels, just a straight tube down since you can stack rockets with no collision. This way the doors are disconnected from the signal that opens the doors for the solar panels, I have automation set up to only allow the rockets to launch outside of meteor showers but if they return during one a few ladders may be broken by the meteors but hey.

I get that the automation mess is a bit confusing but in effect all it does is open and close the doors at the best possible time, and I also have circuitry on the right that I have been testing to turn the scanners off while the rocket is in the silo once again simply for the sake of sustainability (: