Redstone comparators do not test for valid power sources properly

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)