High resolution, long delay timers

[cblack]

I've been thinking that I'd like to set up a way to reliably open bunker doors upon a rocket's return that doesn't involve the space scanner.  Why?  Well, even though the scanner will almost always detect a landing even if covered during a meteor shower, it doesn't always, and that means broken bunker doors.  While one could use a low resolution (but still long delay) timer to open scanner doors just before landing regardless of the meteor situation, and then use the rocket space scanner for the fine resolution, this still leaves your scanner(s) or mesh/airflow tiles subject to damage from impacts.

So I think the best solution is to get a timer that is both high resolution and long delay (100Km planets take a long time to get to and come back from).  I've thought of a few ways to build these, and already built a few, but I'm wondering what other people have made.  To be a little more specific, here's the sort of things I'm looking for in a timer:

• A resolution of 10s (i.e. +/-5s) or or less over 30 or more cycles
• Little or no power consumption
• If using power, it must tolerate power outages that are at least 1 cycle long
• Easily configurable
• Uses only a small amount of map area
• Uses only resources available before space exploration
• Must send an automation pulse (it doesn't matter if it's high or low) the entire duration of the timer (i.e. it only rises/falls when the timer is started/stopped)

I've made a water clock, but that uses electricity which I'd like to avoid if possible.  I've thought of a few ways to do it purely from automation, but these tend to be either be large or difficult to configure.  Anyone have a good solution?

[Craigjw]

With my current setup, I have never had a space scanner fail to open the bunker doors when a rocket arrives.  I would suggest it is your implementation at fault rather than the scanners themselves.

Try connecting your rocket scanners to your meteor detection scanners via some type of automation so that they can make use of the network detection.

I have a simple logic circuit that opens the rocket bunker doors if there is a rocket OR if there are no meteors.

[Kabrute]

water clock

resolution dependent on design, using a vertical water column would provide shorter duration(per row) but higher resolution

[cblack]

6 hours ago, Craigjw said:

With my current setup, I have never had a space scanner fail to open the bunker doors when a rocket arrives.  I would suggest it is your implementation at fault rather than the scanners themselves.

I had this setup for a long time, and maybe 30 or so rocket landings worked flawlessly, even though there were meteor showers for numerous landings.  Then I had it fail once, so I suspect it's just the RNG built into the game.  It can be anywhere from 0 to 200 seconds when the doors are closed, and my luck finally ran out.

6 hours ago, Kabrute said:

water clock

I've already built one of these, but I'm trying to do it with no power usage.  I've thought of several ways to reduce the water clock's power usage, but all of them still require some power, even if only to close a valve.

I'm hoping there's some way to do it purely with automation, as then you never need to worry about power.

Edit: I think I've figured out a way to do it with purely automation.  It's not terribly easy to configure (or even design, as it must take propagation delay into account), but it should be completely powerless.  I'll post some images when it's complete.

Edit2: After much experimentation and analysis, I've given up trying to make it with pure automation.  Why?  Basically, limiting yourself to no powered devices makes any reliable timer impractically large.

Interestingly, I did find a way to make non-deterministic timers out of pure automation circuitry, which I didn't think was possible.  These could be used to generate "random" numbers, so if my dupes feel the need to play the lottery, I've now got them covered.

[Sasza22]

7 hours ago, Craigjw said:

With my current setup, I have never had a space scanner fail to open the bunker doors when a rocket arrives.  I would suggest it is your implementation at fault rather than the scanners themselves.

It was tested and the scanners seem to have their minimal delay set when build. This means a scanner might detect a rocket in time even if fully covered 100% of the time if you are lucky but if you aren`t it will always detect the rocket too late when covered. You pretty much have an 80% chance to get a lucky scanner and if you don`t you need to rebuild it and hope this one works better.

[Craigjw]

So what you are saying is that the scanners on build are using RNG to determine their individual minimum delay?

[Nitroturtle]

5 hours ago, Sasza22 said:

It was tested and the scanners seem to have their minimal delay set when build. This means a scanner might detect a rocket in time even if fully covered 100% of the time if you are lucky but if you aren`t it will always detect the rocket too late when covered. You pretty much have an 80% chance to get a lucky scanner and if you don`t you need to rebuild it and hope this one works better.

I think you and others may have misinterpreted what was determined in the other thread.  The only thing I believe is determined when a scanner is built is a seed value for the randomness.  What this means, is that the test I was performing in that other thread, by reloading and observing the same landing over and over, was invalid.  Because the seed for that scanner did not change, each time I reloaded and observed the landing it was the same.  Only when I started destroying and rebuilding the scanner, did the results change on THAT specific landing.  I don't think that any given scanner will always give the same warning on repeated landings.  At least, that's not what I was trying to point out in the thread you were referencing.