[MC-6077] Comparators causes block updates while idle Created: 04/Jan/13  Updated: 19/Mar/17  Resolved: 18/Feb/13

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Snapshot 13w01b, Snapshot 13w02b, Snapshot 13w03a, Snapshot 13w04a, Snapshot 13w07a
Fix Version/s: Snapshot 13w05a, Snapshot 13w09a

Type: Bug
Reporter: Henrik Lindström Assignee: [Mojang] Jeb (Jens Bergensten)
Resolution: Fixed Votes: 8
Labels: redstone, redstone-comparator

Attachments: PNG File 2013-01-04_21.02.47.png    
Issue Links:
Duplicate
is duplicated by MC-6246 Comparator causing dispensers to tick... Resolved
is duplicated by MC-6287 Dispenser glitch Resolved
is duplicated by MC-6293 4 tick clock is made when Comparators... Resolved
is duplicated by MC-6813 Dispensers Comparators pointing at th... Resolved
is duplicated by MC-7227 Comparator makes Dispenser mad Resolved
is duplicated by MC-7649 Rapid pulse bug with dispensers & dro... Resolved
is duplicated by MC-7696 Camparator doing crazy stuff Resolved
is duplicated by MC-7724 Comparator causing update behind itse... Resolved
is duplicated by MC-8798 comparator Resolved
is duplicated by MC-8922 Redstone bug Resolved
is duplicated by MC-8955 Comparators not causing updates Resolved
is duplicated by MC-9005 This Causes Dispensers to constantly ... Resolved
is duplicated by MC-9375 Unpowered Comparators cause dispenser... Resolved
is duplicated by MC-10563 Dispenser clock not working. Resolved
CHK:
Confirmation Status: Confirmed

 Description   

Even when "idle", the comparators update things 2 blocks in front of it and 1 block behind it.
It seems to be doing it every redstone tick(i think) (2 gameticks) which can cause unecessary lag and problems because dispensers can fire on updates etc.

If you flick the lever in the picture the piston will extend because its being updated by the comparator.

Ok, so i actually checked through the code.
Apparently, the comparator is updating itself + the blocks infront/behind when it gets updated. um, derp?



 Comments   
Comment by Steve Blanding [ 27/Feb/13 ]

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.

Comment by Daniel [ 27/Feb/13 ]

fixed!

Comment by Ultimate Omicron [ 14/Feb/13 ]

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.

Comment by Howzieky [ 08/Feb/13 ]

It's not an issue!

Comment by Matthew Sitton [ 08/Feb/13 ]

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

Yay its back

Comment by Mustek [ 07/Feb/13 ]

The issue is back in 13w06a. Reopened.

Comment by Jake [ 02/Feb/13 ]

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!

Comment by conrad wilson [ 02/Feb/13 ]

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 :/

Comment by Jaden Wong [ 01/Feb/13 ]

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.

Comment by Alex Campbell [ 01/Feb/13 ]

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?

Comment by Howzieky [ 01/Feb/13 ]

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

Comment by Tails [ 01/Feb/13 ]

@Jaden Wong: See MC-8802.

Comment by Jaden Wong [ 01/Feb/13 ]

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.

Comment by Mike Dueck [ 31/Jan/13 ]

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>

Comment by Matthew Sitton [ 31/Jan/13 ]

@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.

Comment by nitoducci [ 31/Jan/13 ]

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

Comment by Anon Ymus [ 31/Jan/13 ]

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

Comment by Matthew Sitton [ 31/Jan/13 ]

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 :/

Comment by Tim Heap [ 31/Jan/13 ]

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

Comment by Jesper the End [ 31/Jan/13 ]

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

Comment by Sorin Iliuta [ 31/Jan/13 ]

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:

Comment by Matthew [ 31/Jan/13 ]

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?

Comment by Henrik Lindström [ 31/Jan/13 ]

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.

Comment by Roadsguy [ 31/Jan/13 ]

Do they still make constant updates when powered?

Comment by AA [ 31/Jan/13 ]

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

Comment by ugster watchig [ 31/Jan/13 ]

I miss it ._.

Comment by Mike Dueck [ 31/Jan/13 ]

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

Comment by Jaden Wong [ 31/Jan/13 ]

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

Comment by [Mojang] Jeb (Jens Bergensten) [ 31/Jan/13 ]

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.

Comment by Steve Blanding [ 31/Jan/13 ]

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.

Comment by Roadsguy [ 31/Jan/13 ]

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?

Comment by Chloe Idun Anderson [ 31/Jan/13 ]

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!

Comment by Steve Blanding [ 31/Jan/13 ]

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.

Comment by Matthew Sladen [ 31/Jan/13 ]

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?

Comment by [Mojang] Jeb (Jens Bergensten) [ 31/Jan/13 ]

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.

Comment by Chloe Idun Anderson [ 31/Jan/13 ]

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.

Comment by Steve Blanding [ 31/Jan/13 ]

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.

Comment by Roadsguy [ 31/Jan/13 ]

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...

Comment by MegaScience [ 29/Jan/13 ]

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.

Comment by Kimitsu Desu [ 29/Jan/13 ]

"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.

Comment by Henrik Lindström [ 23/Jan/13 ]

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

Comment by Chloe Idun Anderson [ 22/Jan/13 ]

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.

Comment by Anthony Martin [ 18/Jan/13 ]

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

Comment by Tails [ 11/Jan/13 ]

Confirmed in 13w02b.

Generated at Sun Jan 12 12:10:00 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.