Detecting returning rockets

[StarSquid]

I’ve finally gotten to the point where I’m launching rockets, and I’m wondering how exactly I should detect returning ones. Currently, I’m using a sort of manual override system: I have a clock sensor linked to the bunker doors and gantry. When I see the rocket is coming back, I open the doors and retract the gantry by setting the active duration of the clock sensor. I’d really prefer to have this system automated, but there are some things I need to know before I put in the time and resource investment,

First off, how does scan quality work for incoming rockets? Do I need a similar network quality (about 22%) to the meteor warning system?

Second, how am I supposed to protect the scanners? Will I need to cover more of the surface with bunker doors?

Third, if each rocket needs its own set of scanners, how do I keep them from interfering with each other while also having room for a meteor detection network?

[fishoutofwater]

this might help

 

[Tonyroid]

Your space scanners all work with each other to detect all incoming events with the same reliability. If you are happy with your scan network quality, you could add a 0% quality space scanner (literally put it anywhere) to control your doors for a returning rocket. Because of that, keeping it protected is trivial. You can simply add a space scanner this way for each of your rockets.

 

[0xFADE]

Try building the rocket silos open at the top. Meteors do not damage the rocket.  You’ll still want some radar to detect them so you can tell they are there if you want to do some full launch automation. 

[StarSquid]

5 hours ago, 0xFADE said:

Try building the rocket silos open at the top. Meteors do not damage the rocket.  You’ll still want some radar to detect them so you can tell they are there if you want to do some full launch automation. 

I have bunker doors at the top to keep the exhaust in. I discovered that steam engines produce exhaust with a higher temperature and mass than the input steam, which means I can run my steam rocket for free (other than duplicant time). I should be able to extract power from it as well.

Also, I have run into a snag: while the meteors are coming down and the bunker doors are closed, network quality drops to zero and the returning rocket smashes through the bunker doors and gantry.

 

[Aelfled]

Perhaps a 'naked' scanner that needs periodic repair, or a water clock customised for the travel time of the launch?

[nakomaru]

10 hours ago, StarSquid said:

Also, I have run into a snag: while the meteors are coming down and the bunker doors are closed, network quality drops to zero and the returning rocket smashes through the bunker doors and gantry.

Rocket scanners don't care about scan network quality. Set your silo to open on rocket scanner signal.

[Grimgaw]

6 hours ago, nakomaru said:

Rocket scanners don't care about scan network quality.

How much (seconds) warning do you get though?

[nakomaru]

8 minutes ago, Grimgaw said:

How much (seconds) warning do you get though?

I think about 45-60 seconds. You basically hook up the rocket scanner (placed anywhere) to the door and a not signal to the gantry and you are nearly done your automation.

Just like ruhrohraggy's post:

[Grimgaw]

7 minutes ago, nakomaru said:

Just like ruhrohraggy's post:

My rockets don't wait 38.2s from launch command to starting engines though. The doors would most certainly get destroyed here.

[0xFADE]

17 hours ago, StarSquid said:

I have bunker doors at the top to keep the exhaust in. I discovered that steam engines produce exhaust with a higher temperature and mass than the input steam, which means I can run my steam rocket for free (other than duplicant time). I should be able to extract power from it as well.

Also, I have run into a snag: while the meteors are coming down and the bunker doors are closed, network quality drops to zero and the returning rocket smashes through the bunker doors and gantry.

 

I saw something pretty cool awhile back. Someone had a freezing loop of super coolant running above a co2 area and that effectively kept all the gas from escaping. Should work just as well for rockets exhaust. 

[Nitroturtle]

1 hour ago, Grimgaw said:

My rockets don't wait 38.2s from launch command to starting engines though. The doors would most certainly get destroyed here.

Rockets won't launch until the doors are open. 

Also, there was a discussion awhile back about @ruhrohraggy's design posted above and we collectively decided that it was possible for a rocket to return without enough time to open the doors using 0% quality scanners.  With that said, I've used this setup in a previous base and it doesn't happen very often.  So as long as you're okay repairing doors occationally, it will work for the most part.

[StarSquid]

22 minutes ago, 0xFADE said:

I saw something pretty cool awhile back. Someone had a freezing loop of super coolant running above a co2 area and that effectively kept all the gas from escaping. Should work just as well for rockets exhaust. 

Unfortunately, that would sort of defeat the point of keeping the steam contained. Now, I might be able to run some petroleum through, get 90-something degree water dripping to the floor, and then run the petroleum through some sort of countercurrent heat exchanger to boil water elsewhere.

[Grimgaw]

2 hours ago, Nitroturtle said:

Rockets won't launch until the doors are open. 

Ah yes, forgot that's a thing.

2 hours ago, Nitroturtle said:

Also, there was a discussion awhile back about @ruhrohraggy's design posted above and we collectively decided that it was possible for a rocket to return without enough time to open the doors using 0% quality scanners.  With that said, I've used this setup in a previous base and it doesn't happen very often.  So as long as you're okay repairing doors occationally, it will work for the most part.

Wasn't the chance of breaking the door 20%?

But then there's been so many so many updates since, that I really don't know. Here's the post @nakomaru mentioned, which mentions 56s warning with 0 visibility.

2 hours ago, Nitroturtle said:

Also, there was a discussion awhile back about @ruhrohraggy's design posted above and we collectively decided that it was possible for a rocket to return without enough time to open the doors using 0% quality scanners. 

Was this the thread you're talking about?

The dates on those posts make me scratch my head.

[SkunkMaster]

using 2 scanners, 1 "active" 1 passive, works better. the passive is kept on, while the active radar is continuously toggled on and off using a powered door.

 

this kind of setup has so far had 99% success for me, only failing when i didn't power the door so the switching wasen't fast enough. i guess a power switch could be more efficient then a door... Anyway, that's what i use, and i always put my radars in a "house", all having 0% visibility.. 

[nakomaru]

Hmm, never seen the rocket break the doors on return. They always seem to open well in advance. And the rocket waits for the doors to open.

What I have seen is when the rocket returns and then the doors start to close, and finishes refueling before they close, it can launch through the doors and break them. So I add about a 45 second minimum delay before any launch.

[fishoutofwater]

On 10/11/2019 at 10:29 AM, nakomaru said:

Hmm, never seen the rocket break the doors on return. They always seem to open well in advance. And the rocket waits for the doors to open.

What I have seen is when the rocket returns and then the doors start to close, and finishes refueling before they close, it can launch through the doors and break them. So I add about a 45 second minimum delay before any launch.

I've seen it, but it was off screen and my bunker door built close to red area though I'm just guessing those are the cause.

as of right now, my bunker door built 3 tiles below red area and has not broken, maybe later.

[biopon]

13 hours ago, Grimgaw said:

Wasn't the chance of breaking the door 20%?

But then there's been so many so many updates since, that I really don't know. Here's the post @nakomaru mentioned, which mentions 56s warning with 0 visibility.

With 0 visibility (and 0 network strength) the detect window is always somewhere between 1 and 200 seconds, evaluated randomly. All that matters is the network strength, the individual scanner strength is only used by the game to evaluate the network strength itself, and the latter is used for detection time calculations. At 50%, your detect window is 100-200, at 75% it's 150-200, etc.

So if all you have is a single dish underground (and again, 0% network strength) and you don't do anything fancy with it, the chance to break the doors is 20% because that's the chance of rolling 1-40. 

When I wrote that post you linked I was just going by my observations, but I'm looking at the game code now.  I'm not going to post snippets as that could be frowned upon, but if anyone wants to check for themselves, dotPeek is your friend, and the objects are called CometDetector and DetectorNetwork. 

If you have a functioning meteor detector network all your rocket scanners benefit from it, and you only need 20% network scan strength to ensure detection at least 40 seconds in advance; but without that there's no such thing as a 56s warning.

I feel pretty good about pulsing a single 0% scanner for meteors and a dedicated 0% scanner for every rocket. With the pulse being 1s off and 2s on, it gives me 53 rolls in any 160-second window, each with with an 80% chance to evaluate 40-200 and warn in time. The likelihood for 53 consecutive 20% rolls is... pretty small.

 

[Yank31]

On 10/10/2019 at 10:31 AM, nakomaru said:

Rocket scanners don't care about scan network quality. Set your silo to open on rocket scanner signal.

13 hours ago, nakomaru said:

Hmm, never seen the rocket break the doors on return. They always seem to open well in advance. And the rocket waits for the doors to open.

What I have seen is when the rocket returns and then the doors start to close, and finishes refueling before they close, it can launch through the doors and break them. So I add about a 45 second minimum delay before any launch.

 

I have seen many of your posts and came to the conclusions to treat what you type as valuable.

 

However I do not experience anything you describe here.

For me, the scanner network quality absolutely does matter when it comes to detecting rocket landing. I have 100% scanner network quality (5 or so scanners on the left side), and then use a covered scanner for each rocket (rockets are on the right side).

This scanner has 0% visibility, and 100% network quality. The signal it sends is linked to a filter, set to 155 seconds, which then goes to open bunker doors (closing is instant).

 

When there is no meteor shower, and thus the left side scanners have clear sky, and thus provide 100% scanner network quality, then the system is flawless and the rocket will land 5s or so after the bunker doors have finished opening (200 sec - 155 sec - 40 sec = 5 sec).

When there is a meteor shower, then things get a hell lot messier. Because the meteor shower does affect network quality by a varying number, depending on its... course (door closing, door closed, door opening, regolith falling, how many regolith). And when the network quality falls under 100%, then I don't detect a rocket 200 seconds before it shows up, and thus... my doors don't open in time.

And they do crush the doors. I've seen it many times now.

At first I thought it was maybe linked to my piloting dupes having the navigation trait (+10% piloting efficiency), which would maybe reduce the landing time by 10% or something, but I do not think this is the case anymore.

I think it's purely linked to the network quality, which in turn is linked to an ongoing meteor shower, or not. Which is annoying to be honest because I don't know how to deal with this X factor (meteor shower y/n -- or, more precisely : what is the current network quality ?) in a reliable way.

 

Also, I've never seen any of my rocket crush the door when they take off. In my game, they will always wait for the doors to open (returning a red message "launchpad blocked" or something, untill the path is clear).

 

9 hours ago, biopon said:

I feel pretty good about pulsing a single 0% scanner for meteors and a dedicated 0% scanner for every rocket. With the pulse being 1s off and 2s on, it gives me 53 rolls in any 160-second window, each with with an 80% chance to evaluate 40-200 and warn in time. The likelihood for 53 consecutive 20% rolls is... pretty small.

 

That sounds pretty smart but I wonder, would this actually differ from what a scanner is already doing?

Provided you don't have a 100% network quality, meaning a 200 seconds guaranteed delay ; are they not rolling the dices every tick or so, already? What would pulsing (the power?) achieve?

[biopon]

20 minutes ago, Yank31 said:

Provided you don't have a 100% network quality, meaning a 200 seconds guaranteed delay ; are they not rolling the dices every tick or so, already? What would pulsing (the power?) achieve?

I have 0% network quality. It doesn't mean a 200s delay. It means the minimum roll is 1, the maximum roll is 200. With 50% network quality, the minimum roll is 100, the maximum roll is 200. With 100%, the roll is 200.

The roll is made only when the scanner instance is created (and I'm 99% sure pulsing the scanner causes this to happen), or when the scanner stops detecting the current event. Even changing what to detect doesn't change the roll. 

By the way, network quality is simply the sum of the individual quality ratings of all your scanners, divided by 6.

[Yank31]

100% network quality is what guarantee a 200s delay, therefore allows for a steady system (because you do know you work with 200 seconds, nothing else). In my eyes, that's the only purpose of it : you eliminate randomness, and that's what I meant to say. The opposite is not true, obviously...

As for rolls, I do not know how they happen. I thought they would roll each seconds / ticks or what have you. But if they do a new roll every time they're powered, then yes, pulsing power would make a lot of sense...

[nakomaru]

@Yank31 Pardon me, I'm very likely wrong about this. Every time I've had a rocket, I've already had a network, and it was influencing it without me realizing it. That's why I'd never seen a rocket bust through a door.

[bobe17]

15 hours ago, Yank31 said:

Which is annoying to be honest because I don't know how to deal with this X factor (meteor shower y/n -- or, more precisely : what is the current network quality ?) in a reliable way.

You know you have 0% network quality if you know there is a meteors shower ongoing and you closed the doors.

Unless you use the pulse system described by biopon, your best bet is to open the bunker doors above the silo as soon as you detect a rocket returning.

 

[Yank31]

7 minutes ago, bobe17 said:

You know you have 0% network quality if you know there is a meteors shower ongoing and you closed the doors.

Unless you use the pulse system described by biopon, your best bet is to open the bunker doors above the silo as soon as you detect a rocket returning.

 

Yes.

In fact this is probably the most reliable situation : when there is a meteor shower ongoing.

 

The pulse is very clever and shows a good knowledge of the game mechanics but I find it a bit exploity. I was rather thinking about using different signals, under different conditions.

- if there's a meteor shower ongoing, then open ASAP (or have faith in the 56 sec rule, i'll try it...) ;

- if there WAS a meteor shower ongoing very recently, then do NOT trust the network to be 100% yet (because regolith), but instead substract something like 30/40 sec (to be determined) ;

- if the meteor shower has ended for more than, say, 60 seconds, then trust the network to be accurate (100%, 200 sec warning).

 

At least that's the idea. Not sure if there could be other conditions.

[bobe17]

what is the purpose of not opening the doors immediately?