Time comparison between clocks

[Chuzzard]

I was comparing options for timers clocks today, and I found out about one-time clock. (A timer that runs only once)
However, looking at the one-time clock, it seems to run through two combinators vs one for the constant clock.

With my limited knowledge of how signals work in this game, I thought that this one-time clock would count up every two ticks. One tick for each pass through a combinator.

To test this, I made a circuit to compare the two.


The steel chest activates both the timers once something is put in.
After ~10 seconds, when each timer hits 600, they light up their respective green light.
Surprisingly, both finish at almost the same time.

Can someone help me understand why?

Blueprint string:
0eNrdWMlu2zAQ/RWC18qB5UhehLaXovci8KkLDFoa20QpUiCptEKgf++QSr0lkmU7aYteDEskZ3lv5pHiA12KEgrNpaXJA83ApJoXlitJEzoHY7lck7wipjQFT/E1sRtmCSNKwsDyHIj70cSy72CI4WvJVzxl0oqKCCXXbmjDJC7QsC4F0838m6/ybv+ZeMNABKxscGz7cUzz9cbiwk8l+pcV4RZyQzBw5YeNBRAk3WDMBF8Zy7T1A96Iiy0vhWUSVGlEhXbmCmMygP4yEGDBT/6xUcL9c2kzmZFUSWN1mVp0R9iacYkrP7J08xibcEEZUhY4boj6IclaA8jmPVrDv7gwVaXEYQxrPByiga+SBpQ72zT58kAdbEw4/G1VAALvUsMZkuXuKYOUZ6AHqcqXXDKrNK1xuczgJ03COrjOwKj+FlCQllsOTTj+oVrIMl+CRg9bOyZnQgwEywu0XSjDmzp5oC6OaHoTB7SiySAKb2K0j+lZrcRiCRt2z9EnTky5TktuFziWbVevuDZ28SSHe65tiW927v2MgQeYNg6QZVe4Q/eQF0z73BL63g2XBtCPUBqzQgqhWSEhdX6NcxS6n8bcXt48o8ltsA3VPSJGde2APoJm1AVxJ0TDFoAe7ewAMhcgdHeIDtbcET7vcIkqbVFeBntRLXxFL1Za5Qsu0Q5NVkwYqFtA1pAdQzx5CnFAR30ZCVsYud2GzTS3mxwsT0+QMjtJys7UdbwA6oZD0IAzszioX1UAstPo7psL6Gls11cVeXAwPLqSoENrbYRF20R+w9FNVxzu6PIyk3HdZOttPUffigsLukVq2/D83JR66RsoHO7p7beLazx0UvsseNN+1R33k+I4+o+keNxPisfnSfEeRK8qxfNTUvz+H5Di2XmdHrdQMDlzN9wK7+301XfDR8k9t/33iHp7AVF3HST5PrhiuzyU1+hYboetnPbRqc6doE2dpme24O0B/6d1/OUa8u9Uw/xVW7ZlZ4k6iZ/1Y3Z2qbj+gc7eiWv4Aqfc+ct17LQvRbPu1j6vlafdrTzueyLpWRkuuLNKY7Qtjfg1S4PJyn/EnzqcvKymd3bxszCH4XnCfC1dex/z7r5k4O9LusU5+n2E7JnR8LlQMG5/J5Hs3TcFVLAlCHfR5O9SPnhquFHuduQeT+w+ntE0jCaz0SSOoyiejOv6FzcFcGg=

[DaveMcW]

The "T<Z → T=1" combinator acts like a constant combinator until the limit is reached. So it adds to the count every single tick.

The two tick delay comes into play when the limit is reached. It stops at 611 instead of 609, because there is two ticks of latency.

[Chuzzard]

Ahh, so does the “T < Z check -> output 1 T” not take a tick?

Is it because the output condition isn’t changing?
I’m trying to figure out what is actually taking a tick of time in the clock.

[Qon]

Ahh, so does the “T < Z check -> output 1 T” not take a tick?

It takes a tick. Not 2 ticks, there is no time between updates. The output is updated every tick, if you select the combinator you see it's inputs and outputs. The output is the result from input of the previous tick, and if you look at the inputs you know what it will output next tick.

Use /editor and time controls to step through what is happening tick by tick to see in detail.

Is it because the output condition isn’t changing?

Yes, kind of. If the inputs don't change then the output doesn't change. But if the input does change and the resulting output is the same then you will see the same thing. The output is updated every tick, computed from the inputs of the tick before, replacing the previous output.

[Tertius]

I’m trying to figure out what is actually taking a tick of time in the clock.

There is a delay (latency) of 1 tick between the input and the output of a combinator. If there is some input at a combinator, the result at the output is created 1 tick later. The processing of the condition or arithmetic operation takes 1 tick. So if the condition turns true at tick X, the output is changed at tick X+1. If this is used as input for another combinator, that output is changed even one more tick later, at X+2.

This behavior is the prerequisite for creating counters in the first place: every tick, the output is fed into the input (this has no latency, because it is directly connected) and a 1 gets added, and the next tick the output becomes the sum. If there was no latency, the counter would run at "infinite" speed.

[mmmPI]

I was comparing options for timers clocks today, and I found out about one-time clock. (A timer that runs only once)
However, looking at the one-time clock, it seems to run through two combinators vs one for the constant clock.

With my limited knowledge of how signals work in this game, I thought that this one-time clock would count up every two ticks. One tick for each pass through a combinator.


The steel chest activates both the timers once something is put in.
After ~10 seconds, when each timer hits 600, they light up their respective green light.
Surprisingly, both finish at almost the same time.

Can someone help me understand why?

This is somewhat similar to having a situation where you have Chest+inserter+inserter+10belt vs chest+inserter+10belt. If you give electricity to the setup at the same time and you look the item on the belts, the lane that only require 1 inserter swing will be a little in front winning the race vs the one with 2 inserters because the first item will be a bit late.

You have one clock with 2 combinators and 1 clock with 1 combinator. It doesn't mean one is 2x as slow or as fast.

Use /editor and time controls to step through what is happening tick by tick to see in detail.

Yes ! +1

You can imagine/picture "the signal" like "an item" on a belt, like "a ball" that can move infinitly fast on wire, but everytime it goes through a combinator it takes 1 tick.

A constant combinator would be emiting a train of those balls like item following each other on a belt with exactly 1 time=1 tick between them. Same when you place an item in the chest to trigger the clocks. It emits a signal continously, so 1 iron plate, next tick 1 iron plate , next tick 1 iron plate.

the base of a clock is a loop that put the first ball 1 position behind, so there is 2 ball at this position, then the 2 balls are put one position behind so there are 3 balls and so on.

The first signal "1 iron pate" you can have it go inside an arithmetic combinator and do +0, the output will be "1iron plate".

You can connect the input and the ouput.

This means the first signal "1iron plate +0" will arrive at the input of the arithmetic combinator at the same time as the 2nd signal "iron plate".

Inside a wire the signals are automatically summed, so what the arithmetic combinator will read as input is 2 iron plate. The first signal that received +0 and looped, and the 2nd signal that was coming just behind with 1 tick lag.

This will repeat , the arithmetic combinator will ouput "2iron plate +0", and this will be summed up with the 3rd signal "1iron plate", so the input will be 3ironplate +0, and so on.

This is not really a clock, this is just a runaway system. A clock involve fancy mechanism to control the system.

You don't need to do the +1 to have something that count to the infinity. +0 is required. The sum is automatic due to the time that one signal takes to propagate trough a combinator. First signal loop around and is summed with second signal, loop around and that makes it 3 loop around and that is 4.

If you were to add +1 on the loop then you would end up in the situation you hypothesized in your OP where the clock would be 2x as fast. 1=>3=>5=>7=>9=>11 instead of 1=>2=>3=>4=>5

[DaveMcW]

Here is a simple clock:

simple-clock.png (75.96 KiB) Viewed 174 times

This "simple" clock is still very complicated! Here are the processing steps it goes through each tick:

1. Delete all signals on the wire from the previous tick (instant).
2. Copy the arithmetic combinator output to the empty wire (instant).
3. Add the constant combinator output to the existing signal on the wire (instant).
4. Copy the final wire signal to the arithmetic combinator input (instant).
5. Add 0 to the arithmetic combinator input and move the result to the arithmetic combinator output (+1 tick).

It's funny that all the important steps happen instantly. Adding 0 takes a whole game tick though!

[Tertius]

I'd like to repeat the /editor tip. If you enter /editor into the chat, you're toggling map editor mode, and in map editor mode it's possible to completely halt tick processing and process single ticks with a hotkey. (map editor mode disables achievements for the current save, so if you don't want this, save your lab environment to a new save).

This way you're able to closely inspect ("debug") all signals, inputs and outputs of a circuit for every single tick.
Once you enter /editor, the "map editor" window appears. Click the big stopwatch icon. You will find a button to stop/start processing (the buttons in the Speed section) and you find a button to single step a tick if tick processing is currently stopped (bottom section).

Invaluable: the predefined hotkeys for start/stop are NUMPAD-0, and the single step hotkey is NUMPAD-,

It's also possible to create a clinically pure lab environment easily: viewtopic.php?p=548574#p548574