Comparators causes block updates while idle

Confirmed in 13w02b.

This behavior is very useful. If it is unintended, it would be nice if this behavior was officially added in some other mechanism.

Because my issue was marked as a duplicate of this issue, despite being different, I'm going to put in a request here as well that it be considered a different bug. My issue is basically the same, except it happens behind the comparator as well. This means comparators are useless for checking dispensers because they cause the dispenser to fire rapidly each time they receive any redstone power. My bug only occurs in the latest snapshot (13w03a) and it actually interferes with gameplay, unlike this bug, which is an annoyance at best.

I added that it updates blocks behind it aswell to the description 🙂

"Ok, so i actually checked through the code. Apparently, the comparator is updating itself + the blocks infront/behind when it gets updated."
Wow, that actually explains MC-7771
I mean, if update queue is lost after chunk unload, that is.

I'm curious how exactly this was fixed. It it was literally fixed in that constant updates are no longer done, this could be disappointing to some redstone specialists who have been trying to adapt to the upcoming changes through the snapshots. But it is understandable, since these are development builds subject to change. Just would have been nice to have this functionality. I was using it to make some really cool things, myself, despite my ill-equiped mind.

Just like BUDs, this was a useful bug used in lots of circuits since Comparitors were added. Now they broke half the circuits using Comparitors since 13w01a... 😞

Once again, you have fixed a "bug" that didn't need fixing. Fixing this breaks SO many useful builds. Anything that wanted to auto-empty a dispenser or dropper now requires much more complex redstone. I would very much like to see this "fix" reversed.

Everyone complaining because they fixed the bug, I don't love it either, but it became necessary. The reason why being that the comparators started doing it to blocks they were supposed to be outputting a signal from, making them completely useless for using with a dispenser to see how full it is. You people need to stop complaining before we even know how they changed it.

Sigh...

Comparators were being updated all the time, even if you couldn't see it. So this was a huge performance bug, beyond the weird/unintentional tick builds.

Wow, what the heck. Why does Mojang always focus on bugs that aren't actually bugs but are helpful in many builds, and completely ignore the real bugs, like corner fence hit boxes?

Chad: Telling people to stop complaining about a change is counter productive. I thought the whole point of making an open database like this was to acquire feedback from the users. I'm really happy that they have provided a place where I can offer my feedback and I completely respect their right to ignore my feedback when they think I'm wrong. But don't tell me not to provide it in the first place. As for your reasoning, it was quite possible to determine how full a dispenser was before this fix, so I have no idea what you were talking about there.

Jeb: I realized that there were performance implications but I still quite liked the behavior. Still, I can understand why you would feel the need to fix it for performance reasons.

What I mean is what I reported in my bug that got called a duplicate of this bug when in Snapshot 13w03a it began to happen behind the comparator as well. This made it so that if you ever powered a dispenser with a comparator hooked up to check how full it was it would fire rapidly, therefore making that functionality useless. I'm sad to say that I've download the snapshot, and while it was certainly improved, it still ticked it to fire around 3 times when I hit the button instead of the once I expect, due to it touching a comparator.

As for providing feedback, what I mean is that saying, "How dare you fix this!" when you don't know what they changed yet is counterproductive. Now that they've released the snapshot you can test for differences and then complain about them, but before the snapshot was released you can't know what's different so complaining solves nothing!

Well, if it lagged, then fixing it is good.

Will they still randomly update like Redstone Torches? Maybe make them update slower than before or something...

But come to think of it, won't using a clock instead for rapid-pulsing actually make it lag more, since there would then be six-ish Redstone blocks all updating simultaneously in a clock? Or would only one block rapid-updating cause the same lag?

Chad: Maybe, if you have space, add a pulse shortener to make it send a single short pulse? Will that make it shoot just once?

EDIT: It seems the bug was updating when idle. Do they still update when powered? 😃

Chad: The snapshot is released. I had played with it before I posted. So I guess you must not have been directing your comments at me? Either way, this is probably getting out of hand. My bad there. I'm not really worked up about this although my excessive posting may make it seem that way. 😉 It's not that big of a deal. I'll stop now.

Chad: Yes, but I think that's more a bug with dispensers/droppers. They fire on neighbor updates if there is power around them (and the tile that was updated counts as a "signal source", as comparators do), regardless if the power was turned off or not. I think we still have a bit of metadata remaining, so we could use that to prevent repeated updates for the same signal.

do I have to bulid a hole clock now to have a pulse for my dispenser? loved this feature

Jeb: I think the constant block updating is really useful. It allows my hidden crafting table to work wonderfully.

Screenshots: http://imgur.com/83QxClQ,SxobRjX

I miss it ._.

RIP the best redstone feature in making deadly, compact traps; compact BUDs; etc... 😞

Do they still make constant updates when powered?

No, when i said "idle", i meant that nothing is changing around them and their state isn't chaning. They can be idle in their on state aswell.

I personally really liked this "bug" it made sending items up with droppers really compact. This was one of the best things that happened to redstone and I know that many have used it in there creations. Is there any way that you could revert the "fix" and have this as a feature?

Noooo! This should have never been reported! It was such a great feature, considering we don't have an actual BUD switch :c You ruined it.... D:

Nooooo..... Why? Isn't this possible at all now?

nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo! 😞 makes upward facing dispensers pointless... back to piston and ladder item elevators i suppose

Well this sucks this was one of my favorite features of 1.5 so far and now i find out it wasn't a feature. So here is an idea how about you guys add it back in but a but differently, because i see how there are conflicts with features. So maybe add it in as a new block or have it interact with the full block of redstone in some way or something.

I had an awesome tiny piston "jeb" door made with this. It was no bigger than the footprint of the piston arrangement it was beautifully simple. But now it doesn't work :/

Any block that constantly causes updates is a really bad idea performance-wise.

Noooooooooo! Just no.
At least have it cause constant updates when powered? D:

@Ymus but that doesn't stop people from making clocks though.

Yes i can see the way it happened to happen in the comparator was bad. but maybe something could be figured out to still have this in the game in some way, because it really is extremely useful and it a useful way to get around the annoyances of the 1 block away powering of pistons if you don't need a BUD.

Jeb:

I say add a "force update block". This way we can still have our compact designs. I found this "feature" really useful, and now it will be gone in 1.5, which is sad. I abuse this feature in my map for resetting the state of decorational trapdoors, as well as my hidden crafting bench that I posted above. Now it isn't possible. I know you guys are working hard in squishing those pesky bugs. But also keep in mind, BUD switches were bugs too. You didn't squish them though. You reimplemented their use in another way (or are planning to).

Please, for all of us engineers. Keep a block updater available. They are so useful.

<applause="cheerful_audience"></applause>

noticed a related bug; pointing a comperator away from a container and break the comperator, the redstone wire stays on

what was wrong with the situation in 13w4a anyway?
in my opinion, "fixing" the comperator only produced even more bugs.

@Jaden Wong: See MC-8802.

Awww! Why did you report this!? This was the most useful feature in 1.5!

If you have a clock, it's obvious that it's constantly updating.
If you just have a comparator, it's not obvious at all.
Not to mention the lag caused by people using comparators for purposes that don't require constant updating.

If you want a clock, why not just make a clock?

this was a one-block-clock.
in my opinion the comparator has to many functionalities (compare, substract, fill-checking, and the "fixed" updater)
Just add a new block updater or a pulser/timer.

so the machine gun effect was a bug? i was using that in ALOT of my machines. ill just use some sort of toggleable pulsar instead :/

I understand this may be a bug, but isn't that what minecraft is based on, for the longest time I have loved the way if a bug came out that people liked it was turned into a feature! For example buds or dispensers detection block updates. I understand if this causes unnecessary lag although it was (for its short time) one of the most us full devices for compaction of redstone, i have seen MANY creations that take advantage of this, within the short week it existed! It the feature cannot be returned (although just to the bock in front of it) please make a similar new redstone item that provides constant redstone updates, possibly only when on!

also it breaks my cannon 😞 http://youtu.be/e0ap1Bwce94?t=1m59s that was the only way i could get 50 TNT to dispense in that short of a time, Please return something with similar functionality!

The issue is back in 13w06a. Reopened.

As of 13w06a comparators have to face each other to cause block updates.

Yay its back 😃

It's not an issue!

In 13w07a, directly pointing a comparator on normal mode at a self-resetting BUD causes the BUD to blink. Setting the comparator to subtract mode stops the pulsing.

fixed!

Unfortunately, yes, it seems to have been completely fixed now. Why was it changed from 13w07a? I thought that was a reasonable compromise. Now the build I was working on is going to need to be quite a bit larger. 😞