The Quantum Water Clock (Modular N-Clock)

[Red Shark]

Do you ever wish that we had more signals than just Red and Green? Some way to orchestrate things so that they trigger sequentially, without implementing a binary sequence of Memory Cells? Want to trigger some automation on cycles 2,3, and 5, but not on cycles 1, 4, 6, or 7?

Presenting the Quantum Water clock!

(Gosh darn it, Otto!)

This is much the same as a standard water clock in terms of concept and setup, with two related advantages:

1. It's modular -- the core circuit able to be extended indefinitely to the left to whatever arbitrary length is desired
2. It's output is quantized -- allowing multiple water clocks to exist as part of the same circuit (A 3-Clock can exist simultaneously as a single water clock, three sequential 1/3 clocks, or a pair of 2/3 clock and 1/3 clocks)

This is still a water clock -- a valve controls how much fluid enters the system, and changing the rate of flow determines how fast the automation output cycle back and forth.

Unlike a traditional water clock, however, the Quantum Water Clock is composed of N circuits connected together. The example above uses a 3-Clock in order to turn on the lamps, one after another. It consists of a base circuit (the right-most), plus N-1 Child circuits, the last of which is an end circuit. Therefore, the smallest Quantum Water Clock is a 2-Clock. (If you want a 1-Clock, use a regular Water Clock instead!)

The Quantum Waterclock takes advantage of flow rules, entering the first shutoff until it backs up. Each successive shutoff triggers the next memory circuit in line, while also flushing the previous circuit, and locking the chamber from further output. Finally, when a packet reaches the final circuit overflow, the automation resets the shutoff valves, allowing the process to repeat.

To embrace 4-Clocks and beyond, simple duplicate the middle circuit, and move the end circuit left.

There's definitely room for improvement (such as determining why there's the brief period of overlap between signals), and I'd ideally like to make the whole contraption more compact if I can, but at this point it's "good enough", and I thought I'd share it with the forum in the hopes the collective brain trust can make use of and/or improve it! (Especially since my first attempt at this discovered a fluid duplication bug...)

[All of this because I want to leave my shine nymph eggs on the ground for at-most 4 cycles before sweeping them up!]

 

[Saturnus]

Related to this but not exactly the same I made a new version of the water clock since we have pipe sensors now.

This simply uses my in-line packet stacker.. And a timer valve.

Here's the most compact version you can make with accurate precision and an easy to divide 3 packet (30000g) buffer.

The automation is a positive edge detector and a 3s buffer to reset it. That means it outputs only a single positive pulse.

Timer setting is using the valve by this equation:

Exact amount of seconds between pulses = 30000 / valve setting in grams desired

Or

Valve setting in grams = 30000 / exact amount of seconds between pulses desired

Precision is obviously limited by the valve only accepting one decimal point. But for most purposes the fact that it's 30000 you divide from plays well into the ONI 600s cycle length.

You can modify it to have virtually any amount of buffering pipe sections. Each time you increase the distance between the bridge in the blockage sensor and the shut off valve by one pipe length you increase the buffered liquid by 10000g, and you increase the reset buffer by 1s.

Hope it's useful.

EDIT: Note that if you shorten it to no distance between the bridge in the blockage sensor and shut off valve to try and make a more compact precision it is sometimes off by one second.

[Grimgaw]

1 hour ago, Saturnus said:

This simply uses my in-line packet stacker..

Out of curiosity, what makes it yours?

[Saturnus]

"But Saturnus", I hear you say, "I want a 24 cycle clock, and 24 (times 600) doesn't divide into 30000 with one decimal place."

No problem. Just use a bit of automation and a clock sensor.

Here's a 24 cycle clock by setting the valve to 2.1g/s which is 23.81 cycles at which point the element sensor goes positive. Then a clock sensor at the end of of the 24th cycle goes positive as well. It does every cycle but it's only picked up by the AND gate when both are on. Then there's a positive edge detector giving a single positive pulse and reset the clock as before (EDIT: I failed to mention the buffer is set to 4s in this case to completely clear the line, and while that does means it's one second off that doesn't matter as it's only used to indicate that you in the 24th cycle and the next clock sensor tick is what actually triggers the clock).

 

EDIT: wrong image the first time. This is correct.

[Yoma_Nosme]

Awesome ideas and greatly built...both of them...

Tbh. I don't go so far in my bases to ever truly need waterclock sensors...or maybe, I just don't recognise the opportunity to implement something so spectacularly complicated(I mean it in a good way)...

So...where or for what would you( @Red Shark and @Saturnus ) use something like that? 

[Saturnus]

20 minutes ago, Yoma_Nosme said:

Awesome ideas and greatly built...both of them...

Tbh. I don't go so far in my bases to ever truly need waterclock sensors...or maybe, I just don't recognise the opportunity to implement something so spectacularly complicated(I mean it in a good way)...

So...where or for what would you( @Red Shark and @Saturnus ) use something like that? 

The most obvious places is where you'd use water clocks before such as in critter ranching to know the exact life span of a critter without guess work. So if you know a critter will die in a fixed number of cycle then you can incubate a replacement and letting it grow from baby in a separate room to drop in exactly when the old critter dies.

Or in solar panel set ups because a meteor season is always exactly 10 cycles long followed by an exactly 4 cycle peace season without meteors. After each meteor shower in a meteor season there's also a maximum 2 cycle pause. That takes the guess work (by only using scanners) out of when you can open the bunker door to optimize power output (and shut down the scanner array when you know it's not needed anyway to save power).

[Yoma_Nosme]

6 minutes ago, Saturnus said:

r in solar panel set ups because a meteor season is always exactly 10 cycles long followed by an exactly 4 cycle peace season without meteors. After each meteor shower in a meteor season there's also a maximum 2 cycle pause. That takes the guess work (by only using scanners) out of when you can open the bunker door to optimize power output

Oh! Yes, that is a great implementation! Ty

[Red Shark]

5 hours ago, Yoma_Nosme said:

So...where or for what would you( @Red Shark and @Saturnus ) use something like that? 

My current base has a shine bug ranch for eggshells / omelettes. When the critter count drops below 8, I divert the next shine nymph egg to a hatching chamber, from which it can enter the main ranch.

I got tired of waiting the full 5 cycles for a shine nymph egg to hatch, however, so this lets me have 5 chambers (only 1 accessible at a time) where eggs are left for 4 cycles before being swept into a storage bin. This way, the eggs are "pre-incubated", and the replacement happens at most after 1 cycle, rather than 5. (And any eggs which crack inside the storage bin simply become eggs and shells, which is what I wanted in the first place)

Overcomplicated? Yes. But I'm an engineer, friend, that's sorta our schtick!

[Argelle]

1 hour ago, Saturnus said:

(..) a meteor season is always exactly 10 cycles long followed by an exactly 4 cycle peace season without meteors. After each meteor shower in a meteor season there's also a maximum 2 cycle pause. (...)

Damned, you made me realize that meteors season is not egal to metors shower !

That leave a room for error to guess as to when the meteors fall. Is a brake a pause in the meteor season or a normal peace season ?!?

Exemple of data recorded:

Peace is therefore not automatically a peace saison but only "no shower detected", and meteors is surely part of the meteors saison but not the full lenght of it?

Would you know the rythm here ? Or even distinguish between iron (10), gold (5) or copper (7) ?

[Saturnus]

@Argelle Well, as I said the maximum break between meteors showers in a meteor season is exactly 2 cycles. If there's no meteors detected for more than 2 cycles that must mean it's peace season. That's how you know that the next meteor detection must mean that peace is over and you start the 10 cycle clock that allows you to have the bunker doors open at the exact time the meteor season ends.

This sometimes means you have the bunker doors opening while meteors are raining down. But trust the clock. At the exact moment the bunker doors are fully open. The meteors stops.

Note: All information I have on the subject is based on QoL mkIII. If anyone can dig through the code and find if anything has changed in the Launch Upgrade that would be immensely helpful.

[Argelle]

thanks @Saturnus !

that's magic

 

So, the only real random thing is the shower or not during meteors saison. And once you determine that the full monthy starts at a said cycle (here 861) it will return every 34 cycles ! (895, 929, 963, etc...). Coupled with nice timers depicted in this topic, that's grant !

[Saturnus]

38 minutes ago, Argelle said:

thanks @Saturnus !

that's magic

 

So, the only real random thing is the shower or not during meteors saison. And once you determine that the full monthy starts at a said cycle (here 861) it will return every 34 cycles ! (895, 929, 963, etc...). Coupled with nice timers depicted in this topic, that's grant !

If you really want to record meteors than I might suggest a test set up with a fully functioning scanner array and a really long pipe. With a memory toggle you then record if there was a meteor in a cycle which lets in a blob of water in the recording pipe. And if there wasn't a meteor in the cycle a blob of oil is let in the recording pipe.

Then you just note which cycle you started on let the game run a few hundred cycles letting the game record if there was or wasn't meteors detected in each cycle without you having to look at the game while it's running. A few such recordings and we should be able to deduce the exact behaviour of meteor and peace seasons.

[Yoma_Nosme]

3 hours ago, Red Shark said:

Overcomplicated? Yes. But I'm an engineer, friend, that's sorta our schtick!

Me too. Btw I said spectacularly complicated...not over complicated it was meant as a compliment.

You've described it well and educationally. 

[Lifegrow]

13 hours ago, Red Shark said:

[All of this because I want to leave my shine nymph eggs on the ground for at-most 4 cycles before sweeping them up!]

Surely this isn't the right build for that?  Impressive stuff though bud, i'm just not sure of any game scenario this would actually be useful for (i've been scratching my head for a few minutes).