[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: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| 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. 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 |
| Comment by PHO [ 01/Sep/16 ] |
|
This is similar to, but definitely not a duplicate of |