[MCPE-16831] Redstone comparators do not test for valid power sources properly Created: 01/Sep/16  Updated: 17/Aug/17  Resolved: 17/Aug/17

Status: Resolved
Project: Minecraft (Bedrock codebase)
Component/s: None
Affects Version/s: 0.15.6, 0.15.90.0, 0.15.10, 0.15.90.8, 0.16.0, 0.16.1, 0.17.0.1, 0.16.2, 1.0.0.0, 1.0.0.1, 1.0.0.7, 1.0.0, 1.0.2, 1.0.3, 1.0.4.0, 1.0.4.1, 1.0.4.11, 1.0.5.13, 1.0.6.0, 1.0.5.54, 1.1.0.0, 1.0.7.0, 1.1.0.9, 1.1.0.55, 1.1.1.0, 1.1.3.1, 1.1.3.52, 1.1.4.51
Fix Version/s: 1.2.0.15

Type: Bug
Reporter: Jason Hunt
Resolution: Fixed Votes: 7
Labels: redstone, redstone_comparator

Attachments: JPEG File MegaSpud 036.JPG     PNG File Screenshot_2016-09-01-00-21-25.png     PNG File Screenshot_2016-09-01-00-22-01.png     PNG File Screenshot_2016-09-01-02-11-03.png     JPEG File attachment402.jpg     PNG File megaspud1.png    
Issue Links:
Relates
relates to MCPE-14668 Redstone repeaters facing into a reds... Resolved
relates to MCPE-16286 Pistons are incorrectly activated whe... Resolved
relates to MCPE-16892 Redstone powers the wrong blocks when... Open
relates to MCPE-11871 Redstone not powering horizontally ad... Resolved
relates to MCPE-16170 Observers powering redstone dust belo... Resolved
relates to MCPE-21898 Redstone torch is on although it shou... Resolved
Confirmation Status: Confirmed
Platform: Phone - Android - Samsung Galaxy Note
CHK:
ADO: 61523

 Description   

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 SuperGeniusZeb: Here is a video demonstrating the bug: https://youtu.be/y1Lza7M0RO0



 Comments   
Comment by Helen Zbihlyj [ 17/Aug/17 ]

Reporter says this is fixed on 1.2.0.15 (or 1.2 beta build 5)

Comment by MaladjustedPlatypus [ 17/Aug/17 ]

Fixed in 1.2 Build 5

Comment by [MCPE Mod] Auldrick [ 24/Jul/17 ]

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.

Comment by [Mojang] Mega_Spud (Jay Wells) [ 21/Jul/17 ]

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:

Comment by Helen Zbihlyj [ 14/Jun/17 ]

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!

Comment by Zeb [ 04/May/17 ]

Revised title to be more descriptive.

Comment by Jason Hunt [ 12/Jan/17 ]

This is what was used before the observer. They are here because they are bugs. They shouldn't work.

Comment by Anomonous Anomonous [ 12/Jan/17 ]

Just use the observer.

Comment by Jason Hunt [ 22/Oct/16 ]

Also affects 0.16.0.5

Comment by Zeb [ 11/Oct/16 ]

Affects 0.15.90.8 (0.16.0 beta build 5).

Comment by Jason Hunt [ 11/Oct/16 ]

Thanks for checking, will update the ticket

Comment by Zeb [ 11/Oct/16 ]

Affects 0.15.10. (Tested on Windows 10.)

Comment by PHO [ 01/Sep/16 ]

This also relates to MCPE-14668.

Comment by PHO [ 01/Sep/16 ]

This is similar to, but definitely not a duplicate of MCPE-16286.

Generated at Sat Jan 11 15:13:05 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.