Delay-line combinators

[scruffyvoltherder]

TL;DR

An adjustable delay line combinator, to allow for signal propogation timing to be adjusted.

What ?

Just an adjustable delay line. equivalent to a line of Each+0=Each arithmetic combinators.

Why ?

It would be a compact way of solving circuit problems caused by timing, without having to make a large string of combinators to create propogation delay.

[LackadaisyFrog]

Compact signal delay has a solution here.

Make a single clock that counts up to 60. This is done by connecting a constant combinator outputting a signal of one (I will call it "A" == 1) to the input of a decider. Then attach the output of the decider back to the input and set it to [When "A" < 60, output "A" (input count)]. Attach the output of this decider to the input of 2 new deciders. Set one to [When "A" == 1, output your read signal], and the other to [When "A" == 31, output your write signal].

Problem solved with 4 combinators If you don't want it to be constantly repeating, you can make a unidirectional clock that only starts counting up when some other signal is sent to it. This is done by taking your clock and instead setting it to [When "B" == 0, output everything(input count)]. Now the clock will count up indefinitely until it receives a signal of "B" == 1, when it resets to 0 and starts over.

Let me know if you need clarification on anything, I would be happy to build it in-game for you.

[scruffyvoltherder]

Compact signal delay has a solution here.

I've used timers like that before, but that doesn't work for certain applications. Sometimes you need a proper delay line.

[LackadaisyFrog]

Compact signal delay has a solution here.

I've used timers like that before, but that doesn't work for certain applications. Sometimes you need a proper delay line.

Perhaps I am misunderstanding your suggestion. I thought you were asking for a compact method to introduce a signal delay, and the link provides two methods. If timed delay using a clock isn't a solution and the situation requires a brute force approach to propagation delay, what would the "delay line combinator" be doing if not using a clock to count down?

[scruffyvoltherder]

If timed delay using a clock isn't a solution and the situation requires a brute force approach to propagation delay, what would the "delay line combinator" be doing if not using a clock to count down?

It would be just like a bunch of "Each+0=Each" combinators in a line. Basically just a brute force propagation delay, but in the form of a single combinator. Internally, it would probably use a circular buffer. Each tick, it takes the signals from the input and put it in the buffer, and outputs the signals in the buffer from x ticks ago. just like how a real-world delay line works.

Timers are great if you need a delay on a trigger signal, but they don't really work for a constantly changing signal that you're doing math on.

[Xerkus]

I wanted this for a long time too.

A combinator with configurable delay in ticks to synchronize precise circuits.
A simple (delay) sized FIFO queue of signals. Each tick input signals are queued while dequeued signals are emitted as output.

It is fairly trivial to make one as a mod but lua will be impacting UPS too much compared to native solution.

[ndh]

How many ticks are we talking about here? I've never had the need for a delay of more than two or three ticks.

From the thread here it's hard to judge if there's an actual need for it, or if there's a significant benefit. So I think some examples would help.

What about memory requirements? For every tick delay it would need one 32 bit number for every possible channel, so # ticks × 172 channels × 4 bytes. What's the limit on the delay? If there's no limit, the space requirement could grow quite large.
That being said, each normal delay combinator also consists of another network, which stores these numbers anyways. So nothing changes.

[Tertius]

I really made many circuit contraptions, and I consider some of them non-trivial, but I never encountered the requirement for having a delay of more than 2 ticks. And for 2 ticks, you can just use 2 combinators. Whenever the need seems to arise for some complex blackbox (and a delay combinator for n ticks is a blackbox, and it is a complex item), I see this as an indication my approach is wrong and I need a different approach where such complexity isn't needed.

If you want this as mod, go for it and create a mod. But for the vanilla game, it's a too specialized, non generic item.

You will probably use single items of this, so UPS impact for a scripted entity is probably trivial. You configure the length of the combinator, for example 10. You allocate a ring buffer with that size and initialize a pointer into the buffer. The ring buffer is an array of array references. A very small thing. Each tick you output the array at the pointer to the output network, then read the signals from the input networks (you get an array of signals) and store the reference to the array you got at the current ring buffer position. Then advance the ring buffer pointer. The most complex task to write such a mod is probably the GUI window to enter the desired buffer length.