Delay combinator

[prdfndr]

Delay combinator: delays a signal by a chosen number of ticks (or, sends a given another signal). Sometimes I want to control things by time and not by events. I feel like the current tools are clumsy (delaying a signal by a minute would require 60*60 combinators). We can control trains by time, why not have similar option for other things?

[prdfndr]

Or, may be just give decider and arithmetic combinator an option of a delay for a different number of ticks than 1

[Koub]

If you loop an arithmetic combinator into itself, doesn't it take 1 tick to process ? If I'm right, then you don't need 60x60 combinators, but just one that counts to 3600.

[foamy]

If you loop an arithmetic combinator into itself, doesn't it take 1 tick to process ? If I'm right, then you don't need 60x60 combinators, but just one that counts to 3600.

Doesn't work, for two reasons:

First: Presumably, the OP wants the original signal value. That requires at least a memory cell, and a clock to determine when to transmit it, which is started on the receipt of the signal. While that's not 3600 combinators, it *is* more than just one.

Secondly: While a memory cell + clock setup will work for a single pulse signal, it will not accurately delay an entire pulse train; it can only handle a single signal every minute. Delaying the entire incoming stream by exactly X ticks can currently only be done via X combinators, as far as I know. What they're after is a combinator that reads arbitrary inputs and then will pass it along, unaltered and in sequence, after a selectable number of ticks.

[Nosferatu]

I do think that is what he wants but what is the use case for this?

[ssilk]

I also miss the why in OP.

This can be build with existing combinators. Not exactly as OP, because as said it would need on combinator per tick.
If wanted I can paste the blueprints.
I think I have mine from here: viewtopic.php?f=193&t=29027
But there are lots of ideas. For example I think the most cpu saving timer is one that works with the length of belts.

And I wish also this would be built into vanilla, but mainly because of cpu efficiency reasons.

[foamy]

I also miss the why in OP.

This can be build with existing combinators. Not exactly as OP, because as said it would need on combinator per tick.
If wanted I can paste the blueprints.
I think I have mine from here: viewtopic.php?f=193&t=29027
But there are lots of ideas. For example I think the most cpu saving timer is one that works with the length of belts.

And I wish also this would be built into vanilla, but mainly because of cpu efficiency reasons.

OP isn't talking about a timer, though. A timer won't give the results needed unless you have a memory cell for each tick, at which point you may as well just build a giant delay block.

@Nosferatu: Signal synchronization is the first one that comes to mind for me. Sometimes there's signals which require different amounts of processing steps but that you still want to arrive at their endpoint at exactly the same tick. Usually this delay is only a tick or two so you can kludge it with an empty arithmetic combinator, but for larger desynchronizations it can blow out the size of a combinator creation pretty fast.

[Nosferatu]

That's the one thing I experienced too but he is talking about a 3600 tick delay.
Clearly that's something different

[prdfndr]

Yeah guys, sorry, the original post did not explain why I really needed it. What I actually wanted, were just two control options:
1. Output a signal for N seconds, if a condition is met. (To let things operate for some time)
2. Output a signal, if a condition is met for N seconds (to avoid flickering).

With a time delay combinator these options are straightforward to implement, meaning, they do not require loops. Circuits without loops are much easier to think about and to debug, which is great for multiplayer (and for single player as well).

In the hindsight, I have to admit, adding the two options directly to the decider and arithmetic combinators could be a more elegant solution. On the other hand, a time delay is a more primitive tool, which, I feel, fits more into Factorio theme

[foamy]

Yeah guys, sorry, the original post did not explain why I really needed it. What I actually wanted, were just two control options:
1. Output a signal for N seconds, if a condition is met. (To let things operate for some time)
2. Output a signal, if a condition is met for N seconds (to avoid flickering).

With a time delay combinator these options are straightforward to implement, meaning, they do not require loops. Circuits without loops are much easier to think about and to debug, which is great for multiplayer (and for single player as well).

In the hindsight, I have to admit, adding the two options directly to the decider and arithmetic combinators could be a more elegant solution. On the other hand, a time delay is a more primitive tool, which, I feel, fits more into Factorio theme

Oh, both of those are pretty easy to achieve with latches. Grant you, not everyone knows how to work with latches, but there's some tutorial stuff on the wiki.

An actual proper delay combinator would have some unique use cases that are not easy to replicate with current combinators. For example, suppose you wanted something that detected the net change in something over the last, rolling minute (like how the production stats screen works). This wouldn't be an out-there thing to want -- inventory control's pretty integral to Factorio -- bu it's also straight up impossible to do without an outrageous number of combinators. The next best thing is some kind of clocked read, but that means the information could be quite stale.

The more I think about it the more I like the idea of it.

[prdfndr]

Yeah, measuring signals averaged over some time would be a good example of application. Actually, anything that involves time would be much easier to implement.

I do not see though, how latches would solve the two problems I wrote. I imagined a solution to the problems would involve making a countdown timer that is reset by a signal, which is a tricky thing to do, and you, probably, should not do it in a multiplayer (no one is going to understand it).

[foamy]

Yeah, measuring signals averaged over some time would be a good example of application. Actually, anything that involves time would be much easier to implement.

I do not see though, how latches would solve the two problems I wrote. I imagined a solution to the problems would involve making a countdown timer that is reset by a signal, which is a tricky thing to do, and you, probably, should not do it in a multiplayer (no one is going to understand it).

Clocks are two combinators; they're not complicated devices. If all you're doing is blocking out a chunk of time and then outputting some averaged value, or holding a given signal for X time, they and a latch they control are all you need. No reason not to use them in MP, even. There's a lot worse in the way of circuit goop than that out there :v

What a delay combinator would do would give you the ability to continuously compare signals with a known time displacement. This is already done for singular tick delays in edge detectors, but a delay combinator would allow for implementations that would otherwise require absurd numbers of combinators to achieve the same effect.

The continuous comparison is the unique piece this would offer.