0

I was playing around with a self-referential comparator pulser and came across something I don't understand.

In short, it's a comparator in subtraction mode, with the output of the comparator fed back into the side input of the same comparator along the edges of a 3x3 square.

The premise of using a self-referential comparator to make a pulser makes sense to me, and if I add repeaters to this design it works exactly as I'd expect. Without repeaters, something very odd happens.

The comparator produces a steady on signal, but only close to its output. As you move further away from the comparator, it begins producing rapid pulses, which degrades to no signal at all further way. If I increase the signal going into the comparator, the same basic pattern happens but at different distances from the output.

To me, what seems to be happening is:

  1. The blocks closest to the comparator output are getting a pulse signal where the ON pulse is long enough that the off pulses don't register [1-1-1-1-1-1-1-0-1-1-1-1-1-1-1-0-1-1-1-1-1-1-1-0 etc]

  2. The blocks furthest away are getting the opposite, a pulse signal where the ON is so short that it's not long enough to turn the blocks on [0-0-0-0-0-0-0-1-0-0-0-0-0-0-0-1-0-0-0-0-0-0-0-1]

  3. The blocks in the middle are getting a pulse signal that is able to be processed in a meaningful way [1-1-0-0-1-1-0-0-1-1-0-0-1-1-0-0-1-1-0-0-1-1-0-0]

  4. Increasing/decreasing the signal strength scales the lengths of these output sections accordingly

Assuming the above is accurate (it may very well not be, I don't think I'll ever truly understand redstone circuits) I really do not understand why distance from the pulser affects the rate of the pulse signal.

  • 1
    Can you please make your screenshots with the Vanilla textures (or close to them)? I have no idea which blocks you're using there. – Fabian Röling Aug 27 at 16:02
  • 1
    It's still very hard to visualise what is actually going on. – Fabian Röling Aug 27 at 18:45
  • 1
    No, Python and Java are both regular programming languages that are made to be readable. But you can have arbitrary textures as a resource pack, so it's like complaining that someone writes their C program with a preprocessor that replaces random keywords with random other words. And in general, if you want people to help you, don't make it needlessly harder for them. – Fabian Röling Aug 27 at 23:20
  • @MikeTheLiar It's nice to see you turn around so suddenly. To the point: Fabian's just asking to make it even clearer. You don't see the point of putting more effort into something that in your opinion is already clear enough. End of story. I have no clear concept of Minecraft, but I think it's clear what you are asking. – Joachim Aug 28 at 12:48
3

A comparator has 2 modes

Compare mode (torch unlit):

  • Check if the signal coming in from the back is greater than or equal to the signal strongest signal from either side.
    • If yes, emit the power of the back side to the front side
    • If no, emit no power to the front

Subtract mode (torch lit):

  • Check if the signal coming in from the back is greater than or equal to the signal strongest signal from either side.
    • If yes, emit the difference in power from the sides vs the back side to the front side
    • If no, emit no power to the front

In your case, you made a loop of 7 redstone wires long to the side of the comparator.

Lets assume you just placed a lever behind the back of the comparator, and that you just turned the lever on. (this is like your last example)

  1. The comparator (compare mode) now receives a signal of 15 from the back, and 0 from the sides. It will emit a signal 15 the next tick.
  2. The comparator (compare mode) now receives a signal of 15 from the back, and 9 (15 - 7 + 1) from the sides. It will emit a signal 15 the next tick.

As you can see, a comparator in compare mode is "stable", lets toggle the mode

  1. The comparator (subtract mode) now receives a signal of 15 from the back, and 9 (15 - 7 + 1) from the sides. It will emit a signal 6 (15 - 9) the next tick.
  2. The comparator (subtract mode) now receives a signal of 15 from the back, and 0 (6 - 7 + 1) from the sides. It will emit a signal 15 (15 - 0) the next tick.
  3. The comparator (subtract mode) now receives a signal of 15 from the back, and 9 (15 - 7 + 1) from the sides. It will emit a signal 6 (15 - 9) the next tick.
  4. The comparator (subtract mode) now receives a signal of 15 from the back, and 0 (6 - 7 + 1) from the sides. It will emit a signal 15 (15 - 0) the next tick.

This doesn't look very stable at all...

Using the values, we can also explain what the trap doors are doing.

  • The trap doors in the green region are between 0-6 tiles away from the comparator, meaning they always see the full signal
  • The trap doors in the yellow region are between 6-15 tiles away from the comparator, meaning they see the signal going on and off quickly
  • The trap doors in the red region are between further than 15 tiles away from the comparator, meaning they never see the signal

The lamps take 2 ticks to turn off, meaning they don't react quickly enough for the fast clock.

  • Thanks for the explanation, that makes perfect sense when you walk through it step by step. – MikeTheLiar Aug 27 at 15:17
  • What I've discovered here is that I need to get a hold of a redstone debugger somehow. – MikeTheLiar Aug 27 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.