Opening bunker doors, for rockets, during meteor showers

[Yank31]

2 hours ago, Nativel said:

- I see. sorry can't help you.

Turns out i did put old underwear on my head, for halloween, when younger. Such comfort.

 

I get what you say, good common sense too, however 2 things :

- I like doors. And automation. Is a game. Also picture a little guy regularly sending rocks into your barrel. Not nice.

- meteors drunk, cant fall straight. So while bunker tiles on ground are indeed good - they do mix quite well with insulated mafic, marking the spot nicely - if you go without doors, you will want those on the walls as well. Else walls go wtf. Do you have tall rockets? I do, they're 55 tiles tall. That's ~ 120 steel tiles just for 1 silo walls. 12 tons.

2 bunkers doors are worth one ton (that's twelve times cheaper).

 

We do have a scanner that can detect returning rockets. What could this be for?

 

55 minutes ago, OxCD said:

I do appreciate this topic as this question also popped-up to me.

As an alternate way, you can completely avoid scanner and build water clock system that allow you to time exactly when the rocket will return. Could be a manual system, where you choose when your rocket is taking off, so you set the timer manually every time, or could be a cyclic system, when the rocket is set for "auto-launch", and then you use the output automation port of the rocket to start the clock, which have always the same length.

Now you're talking to me.

Yes... yeeeeeees, I can see it taking form now.

[nakomaru]

Steel walls all around are what you want for a silo anyway if you are opening during a storm. Plus they conduct heat to your silo cooling system much better than insulation.

Nativel/Ket's and OxCD's approaches are both nice. No need for doors really, but I prefer to keep an atmosphere in my silo to keep it nice and chilled.

[tzionut]

@Yank31 in my previous savegame i used a buid from biopon for rocket detection paired whit one auto rocket launcher, and loader for oxidizer and fuel..When i will be home i will make for you some printscrens. No busted doors, minimum power consumption.

Post edit:

Rocket detection: Biopon 2 second filter coupled whit a power switch for the scaners

Auto rocket launch: 30 s buffer coupled whit a not circuit for preventing the damage done to the crane at landing

Auto refuiling: 5 second buffer + not gate input for a and gate comand the start of the pumping when atmo sensor detect gases (above 1000 for preventing starting if a commet struck before the doors are closed after launch), and the element .pipe sensor stop pumping

Same circuit repeated for my hidrogen rocket.

Bonus: autocooling: before modification of the steam turbine, now you can do the same thing whit a steam turbine paired whit anaqutuner.

Spoiler

[Yank31]

On 18/10/2019 at 9:22 AM, OxCD said:

I do appreciate this topic as this question also popped-up to me.

As an alternate way, you can completely avoid scanner and build water clock system that allow you to time exactly when the rocket will return. Could be a manual system, where you choose when your rocket is taking off, so you set the timer manually every time, or could be a cyclic system, when the rocket is set for "auto-launch", and then you use the output automation port of the rocket to start the clock, which have always the same length.

On 18/10/2019 at 11:34 AM, tzionut said:

@Yank31 in my previous savegame i used a buid from biopon for rocket detection paired whit one auto rocket launcher, and loader for oxidizer and fuel..When i will be home i will make for you some printscrens. No busted doors, minimum power consumption.

I'm coming back to this.

I did build a water clock, of Saturnus design (mostly - made it twice as large and changed the calibration / reset logic). The clock is set to follow the meteor seasons and automatically launches the rockets when they will come back into a peace period (that required scheduling on my part). And, obviously, close the silo doors after them.

During peace periods, the water clocks automatically turns off all my meteor shower scanners (I have 6, for 100% network) to save power (I do have 6 of them...). However, when a rocket has been launched and is planned to return, then the system automatically overrides this for a brief period of time (400s) and turns all the meteor shower scanners ON again, as well as the concerned rocket scanner.

Because this has been scheduled to always happen during a peace season (and quite long into it, so there can't be any regolith still being cleaned and blocking the sky - miners have had 2,5 cycles, since the very last shower possible, to clean it), firing the meteor scanner array is guaranteed to provide a 100% network quality, thus allowing the rocket scanner to emit a guaranteed 200s warning when a rocket is coming back. The system can thus command to open the silo doors on a reliable 160 seconds delay after that, and 40 seconds later, the silo doors are opened as the rockets get back in.

 

Then, well then the system closes the silo doors of course (those doors...) as the rockets touch the ground (rocket scanner red signal), and makes them wait inside, under closed doors, for the end of the peace season (~1,3 cycle left). They automatically get refueled (one after the other) during the start of the next meteor shower (whichever it is, doesn't matter) and wait for the next peace season to, automatically, and simultaneously, launch again.

 

It is full auto, with doors (that only open for letting a rocket fly by and will never be smashed).

 

The overall wiring looks like this :

(not done yet, only 2 rockets have been hooked, need 2 more. Also there's some "unnecessary" stuff, like a display for the clock.)

 

In some places I went over-board with the wire bridges (especially under rocket scanners - top right) but it's meant to look nicer when you're not in automation interface :

(not done either, but... this game can be very time demanding...)

 

At any rate, it is indeed possible to always open bunker doors on time, for rockets landing. It is quite involved, but it can be achieved, in full auto, in vanilla, and without tricks. The good boy way. So thanks all for the suggestions, piling them up brought me there.

I'm happy now

 

[Tobruk]

On 10/18/2019 at 5:42 AM, Saturnus said:

But if you want to make absolutely sure you never have broken doors then you can use my updated water clock

It says I don't have permission to see this post. Anyone has the same problem?

[biopon]

6 hours ago, Tobruk said:

It says I don't have permission to see this post. Anyone has the same problem?

Yes, @Saturnus must have made it not visible.

By the way, is there any information on the current peace/storm mechanic, or is the old ONI Meteorology post by bugfix still up to date? Saturnus hinted that it has changed somewhat, that's why I was trying to look up that post. Google just gives me the bugfix article and a whole lot of old discussion.

 

12 hours ago, Yank31 said:

I'm happy now

Very nice work, congrats. One nitpick about this though: I can imagine it working at the super endgame when you have hydrogen rockets going to far-off destinations on a regular schedule. Early on when you're trying to science the planets, and sending petroleum rockets to newer and newer destinations so you can get more of the resources that you discover, it must be a pain in the neck to calculate a new schedule for every new destination.  Or am I wrong?

 

[Lancar]

I made 2 naked scanners to boost the network strength at all times, and just eat the repair costs. It's not 100% foolproof but it greatly minimizes the chances of door collapse as when one gets covered by regolith the other still improves the odds while the first one is being dug out by the robo miners.

[nakomaru]

3 hours ago, biopon said:

By the way, is there any information on the current peace/storm mechanic, or is the old ONI Meteorology post by bugfix still up to date?

Wiki appears to be correct. 10/4/7/4/5/4. Iron/peace/copper/peace/gold/peace. 34 cycle cycle.

[Yank31]

Yes, the wiki is correct, down to the respite timings during showers. Also seasons still seem to be counted on every cycle start, meaning that you sometimes get false positives (that is to say, meteor scanners will sometimes emit green during the first day of peace, but nothing will fall), both I had occurred "the day after" a meteor season (iron season "11th" and gold "6th").

Also yes, Saturnus has probably removed his topic, the contraption was... not functional yet (well, everything was, except the self calibration). I asked him about that and next day topic was gone.

 

4 hours ago, biopon said:

Very nice work, congrats. One nitpick about this though: I can imagine it working at the super endgame when you have hydrogen rockets going to far-off destinations on a regular schedule. Early on when you're trying to science the planets, and sending petroleum rockets to newer and newer destinations so you can get more of the resources that you discover, it must be a pain in the neck to calculate a new schedule for every new destination.  Or am I wrong?

Thanks

It is a quite involved build and therefore best suited for end game I think, yes. However it has all the information one would need to do basically anything, in full auto. One could build a clock with as many ports as needed (just need heavy planning and space... I did not put my own in the best spot, in that regard). My clock has 14 ports and I use 13 I think...

Overall my setup produced some sort of circular logic : automation and clock is what allow me to track the seasons and open my doors with 100% accuracy, however if everything is automated then I should have a rocket program that takes advantage of it. Meaning cargo trips in loops. The whole system has evolved around, and for that.

Engine type hardly matters here, because it turns out, according to me anyway, the best destinations for this are the closest ones (replenish rate, travel time, frequency of launches and autonomy considered), so my rockets are sent to 10k and 30k asteroids. With their schedule, the expected depletion of their targets, aka the autonomy of the route, is 1228 cycles for the 10k ones, and 193 cycles for the 30k ones. That's the amount of time they can operate in full auto, before I need to change their destinations.

 

Now, changing destinations every time is... well, the opposite of full auto. You would really not want your science rocket to get launched back to the same destination. I can't see it being a problem for the setup though, it's just a matter of knowing when you launch (say third day of peace season #2) and adding the travel time to that (say 37,8 cycles), meaning it would land the next long cycle, 3,8 cycles after it launched. Meaning this schedule sucks because it would land during a meteor shower.

So foreseeing this you instead launch it during the very first day of peace time #2. And you set a port to track launch day + 3,8 cycles worth of 10g/s water, hook that to the scanners override and voila.

 

That said, yes, it is not meant for exploring, it is meant for regular trips in full auto. I'm convinced power toggling is much simpler, lighter, I mean... just look at this :

It's not exactly light, and that's only the clock...

 

I know @bobe17 was working on a different clock that tracks safe windows of launch for many distances at once. Like... emits green when it's safe to go 10k, 50k and 120k (random numbers). That approach would probably work better for semi-auto & science, in the "early late game"

[biopon]

4 minutes ago, Yank31 said:

It's not exactly light, and that's only the clock...

I suspect some of those AND gates could be replaced with a NOT. It's an optimization that comes up here every now and then. This is what it looks like:

These are functionally equivalent if, in the NOT gate version, the inputs are set to the opposite condition (above instead of below, etc.) A limiting factor is that the wires are crossed to make an OR, so you can't use the individual input signals separately elsewhere unless you mitigate this but then you may as well use an AND. Still, very useful sometimes.

 

[Yank31]

Interesting... I need to digest that, there are some multi purpose signals (left side) but mostly not, so this could prove quite useful (looking at my picture, it's... it could use the help).

I've been trying to simplify my circuits (not necessarily showing, here), is there a compendium of those alternate versions?

[bobe17]

2 hours ago, Yank31 said:

I know @bobe17 was working on a different clock that tracks safe windows of launch for many distances at once. Like... emits green when it's safe to go 10k, 50k and 120k (random numbers). That approach would probably work better for semi-auto & science, in the "early late game"

It was based on this topic

https://steamcommunity.com/sharedfiles/filedetails/?id=1894475506

With the first sensor before shutoff for the actual cycle, the second sensor for 10000km, etc. clock set on 0%/1%. buffer 1s

The loop covers the destination from 10000 to 100000km.

1/ I tried to reuse the loop for the destination above 100000km but a packet is always being on the input of the shut-off, so the prediction is wrong above that distance (workaround: a loop covering 34*2 cycles +2 pipes for the shut off)

2/ The position of the sensors changes if the dupe has the 10% navigation efficiency bonus ^^

[Z0366]

On 10/18/2019 at 3:40 AM, Ketmol said:

 

LOL, yes, build bunker walls around the rocket and leave the top open, some players prefers to do that. But I use ladder scaffolding alot so it is not for me.