Redstone comparators do not test for valid power sources properly
1st BUD Placing a comparitor with a block behind it. Then an unpowered repeater going into the block anywhere. Placing a torch on any other side of the block. At this point placing a block on or to the one side left of the original block placed will cause the comparitor to update. break the block, place it again to cause the update to happen again.
2nd is place a block, place a lever on 1 side on the block. Place another lever next to block. Place dust from the back of the 2nd lever and connect it to the other lever. the dust will connect to the back and side of the second lever and run next to the first torch.
The 2nd lever needs to be on. place a comparator in front of the block. now anything that is placed next to dust that connects the levers will cause the comparator to update.
Edit by Zeb: Here is a video demonstrating the bug: https://youtu.be/y1Lza7M0RO0
Linked Issues
relates to6
MCPE-14668Redstone repeaters facing into a redstone dust dont redirect the dust serverside, only graphicallyFixedMCPE-16286Pistons are incorrectly activated when adjacent to a block that is adjacent to an activation-power source, but the block is not powered by the power sourceFixedMCPE-16892Redstone powers the wrong blocks when redirected by pistonsConfirmedMCPE-11871Redstone not powering horizontally adjacent blocksFixedMCPE-16170Observers powering redstone dust below do not power components adjacent to the dustFixedMCPE-21898Redstone torch is on although it should be offIncomplete
![[Mojang] Mega_Spud (Jay Wells)](../../../data/avatars/users/92696.png){kind=small}
Created Issue:
A block, comparator, unpowered repeater, and a torch cause a BUD update
Placing a comparitor with a block behind it. Then an unpowered repeater going into the block anywhere. Placing a torch on any other side of the block. At this point placing a block on or to the one side left of the original block placed will cause the comparitor to update. break the block, place it again to cause the update to happen again.
Attachments2
relates to
Placing a comparitor with a block behind it. Then an unpowered repeater going into the block anywhere. Placing a torch on any other side of the block. At this point placing a block on or to the one side left of the original block placed will cause the comparitor to update. break the block, place it again to cause the update to happen again.
1st BUD Placing a comparitor with a block behind it. Then an unpowered repeater going into the block anywhere. Placing a torch on any other side of the block. At this point placing a block on or to the one side left of the original block placed will cause the comparitor to update. break the block, place it again to cause the update to happen again.
2nd is place a block, place a lever on 1 side on the block. Place another lever next to block. Place dust from the back of the 2nd lever and connect it to the other lever. the dust will connect to the back and side of the second lever and run next to the first torch. The 2nd lever needs to be on. place a comparator in front of the block. now anything that is placed next to dust that connects the levers will cause the comparator to update.
A block, comparator, unpowered repeater, and a torch cause a BUD update2 different BUD update layouts that should not work
1st BUD Placing a comparitor with a block behind it. Then an unpowered repeater going into the block anywhere. Placing a torch on any other side of the block. At this point placing a block on or to the one side left of the original block placed will cause the comparitor to update. break the block, place it again to cause the update to happen again.
2nd is place a block, place a lever on 1 side on the block. Place another lever next to block. Place dust from the back of the 2nd lever and connect it to the other lever. the dust will connect to the back and side of the second lever and run next to the first torch.The 2nd lever needs to be on. place a comparator in front of the block. now anything that is placed next to dust that connects the levers will cause the comparator to update.1st BUD Placing a comparitor with a block behind it. Then an unpowered repeater going into the block anywhere. Placing a torch on any other side of the block. At this point placing a block on or to the one side left of the original block placed will cause the comparitor to update. break the block, place it again to cause the update to happen again.
2nd is place a block, place a lever on 1 side on the block. Place another lever next to block. Place dust from the back of the 2nd lever and connect it to the other lever. the dust will connect to the back and side of the second lever and run next to the first torch.
The 2nd lever needs to be on. place a comparator in front of the block. now anything that is placed next to dust that connects the levers will cause the comparator to update.
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
2 different BUD update layouts that should not workRedstone comparators do not test for valid power sources properly
1st BUD Placing a comparitor with a block behind it. Then an unpowered repeater going into the block anywhere. Placing a torch on any other side of the block. At this point placing a block on or to the one side left of the original block placed will cause the comparitor to update. break the block, place it again to cause the update to happen again.
2nd is place a block, place a lever on 1 side on the block. Place another lever next to block. Place dust from the back of the 2nd lever and connect it to the other lever. the dust will connect to the back and side of the second lever and run next to the first torch.
The 2nd lever needs to be on. place a comparator in front of the block. now anything that is placed next to dust that connects the levers will cause the comparator to update.Edit by Zeb : Here is a video demonstrating the bug: https://youtu.be/y1Lza7M0RO0
relates to
![[MCPE Mod] Celesian](../../../data/avatars/users/81635.png){kind=small}
This is similar to, but definitely not a duplicate of
MCPE-16286.This also relates to
MCPE-14668.Affects 0.15.10. (Tested on Windows 10.)
Thanks for checking, will update the ticket
Affects 0.15.90.8 (0.16.0 beta build 5).
Also affects 0.16.0.5
Just use the observer.
This is what was used before the observer. They are here because they are bugs. They shouldn't work.
Revised title to be more descriptive.
Hi folks! The devs would like some feedback on how the community would like to see this work going forward in the future. Can someone please comment with some specific ways here? Thanks so much!
A simple example, is that the lever shown here should never activate the comparator:
What is happening is the comparator is being activated when the block is updated in a particular order (wrongly, of course) as shown by the sequence here:
There are two ways to analyze these circuit configurations: Either the comparator is measuring the power level of the solid opaque block, or it is measuring the state of the block on the opposite side of it.
In the first case, a lever adjacent to a solid opaque block should only power it if the lever is attached to it and is toggled on, and a redstone torch should only power it if the torch is beneath it. Neither condition applies in these configurations, so the block should not be powered and the comparator should always output zero.
In the second case, the comparator would have to be detecting the fullness of a container or the state of a certain handful of other blocks. Neither the lever nor the redstone torch is a container, nor is it one of these certain blocks, so the comparator should see nothing it can measure in these configurations and again it should always output zero.
If the devs are asking for feedback, I can only imagine they're considering sanctioning the reported behavior either by a change to one of the preceding general rules or by adding a special case rule. Changing the general rules would be extremely unwise, especially for the redstone torch which is used in so many circuits with so many purposes; it would certainly break the majority of them. But making another special case rule would further complicate the task of redstone designers who already have to remember so many of them. It should only be done for a compelling reason.
Although the reported behavior might have some value, it's hard for me to imagine a situation where it couldn't be accomplished with only slight modifications to the circuit to cause the block to be powered in the normal way. I just don't see any justification for sanctioning this behavior with a special case rule. Likewise, the notion of adding levers and/or redstone torches to the list of blocks whose state a comparator can measure makes no sense, because their "state" is merely their redstone power output level, which the comparator already measures as a basic function. The special case rule would only be useful in allowing it to measure the lever or torch through a solid opaque block, which might have some rare advantage but isn't something I'd call a compelling reason.
To summarize, I recommend that whatever causes the comparator to respond in these configurations be considered an actual bug to be fixed, not a feature to be sanctioned. The devs avoided polluting PE with quasi-connectivity for sound reasons, and I think those reasons apply to this situation.
Fixed in 1.2 Build 5
Reporter says this is fixed on 1.2.0.15 (or 1.2 beta build 5)