| Type: | Bug | ||
| Reporter: | Wululululu | Assignee: | [Mojang] slicedlime |
| Resolution: | Fixed | Votes: | 45 |
| Labels: | redstone, redstone-comparator, redstone-signal | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Category: |
(Unassigned)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Situation: Steps to reproduce: Expected behaviour: Code analysis by marcono1234 here |
| Comments |
| Comment by RedCMD [ 26/Sep/19 ] |
|
Still happens in the latest 19w38b snapshot |
| Comment by RedCMD [ 17/Sep/19 ] |
|
Observers cant detect a bugged comp turning off or on |
| Comment by RedCMD [ 15/May/19 ] |
|
This bug can cause timings issues in redstone contraptions Put the comparator in the bugged on state |
| Comment by Wululululu [ 24/Feb/19 ] |
|
Still confirmed for the current Snapshot 19w08b. |
| Comment by Kraif [ 05/Sep/18 ] |
|
Confirmed for 1.13.1. |
| Comment by Антон [ 04/Aug/18 ] |
| Comment by Антон [ 04/Aug/18 ] |
| Comment by pieter12345 [ 27/Jun/18 ] |
|
This bug has apparentally been around since at least 2013 and has never been fixed for some reason. This caused me to fix it in a modified CraftBukkit clone a few years ago and re-apply it to new versions on release, up to 1.12.2. With this message, a screenshot of the commit that fixes the bug is included. The change is done to a method I believe should return true if the comparator outputs (and the two torches should be on), and returns false when the comparator does not output (and the two torches should be off). This method currently returns true if inputPower >= sideInput, but this should be inputPower > sideInput for the case when the comparator is in subtraction mode.
|
| Comment by Dylan [ 27/Jun/18 ] |
|
Can confirm for 1.13-pre4 |
| Comment by [Mod] NeunEinser [ 23/Jun/18 ] |
|
Can confirm for 1.13-pre3 |
| Comment by [Mod] NeunEinser [ 26/Oct/17 ] |
|
Can confirm for 17w43a/b |
| Comment by [Mod] NeunEinser [ 24/Jul/17 ] |
|
Can confirm for release 1.12 |
| Comment by user33 [ 20/May/17 ] |
|
Confirmed for 1.12-pre5 |
| Comment by kaioker radon [ 03/Nov/16 ] |
|
these jammed comparators occasionally give false readings when it is next used. |
| Comment by Marcono1234 [ 01/Mar/16 ] |
|
Please link to this comment in the description of the report. The following is based on decompiled version of Minecraft 1.8 using MCP. All method and class names are the names used in the decompiled version. The reason why this happens is that the private void func_176462_k(World worldIn, BlockPos p_176462_2_, IBlockState p_176462_3_) method of the net.minecraft.block.BlockRedstoneComparator class updates the comparator if the old value is not different to the new value. private void func_176462_k(World worldIn, BlockPos p_176462_2_, IBlockState p_176462_3_) { int var4 = this.func_176460_j(worldIn, p_176462_2_, p_176462_3_); TileEntity var5 = worldIn.getTileEntity(p_176462_2_); int var6 = 0; if (var5 instanceof TileEntityComparator) { TileEntityComparator var7 = (TileEntityComparator)var5; var6 = var7.getOutputSignal(); var7.setOutputSignal(var4); } if (var6 != var4 || p_176462_3_.getValue(field_176463_b) == BlockRedstoneComparator.Mode.COMPARE) { // Replaced this //boolean var9 = this.func_176404_e(worldIn, p_176462_2_, p_176462_3_); boolean var9 = var4 > 0; boolean var8 = this.func_176406_l(p_176462_3_); if (var8 && !var9) { worldIn.setBlockState(p_176462_2_, p_176462_3_.withProperty(field_176464_a, Boolean.valueOf(false)), 2); } else if (!var8 && var9) { worldIn.setBlockState(p_176462_2_, p_176462_3_.withProperty(field_176464_a, Boolean.valueOf(true)), 2); } this.func_176400_h(worldIn, p_176462_2_, p_176462_3_); } } Changing it this way also requires the private int func_176460_j(World worldIn, BlockPos p_176460_2_, IBlockState p_176460_3_) method to be changed as this method returns a wrong power level the comparator should have when it is in compare mode. This wrong behaviour also creates unnecessary block updates when the comparator is in compare mode and the side power level is greater than the input power level. private int func_176460_j(World worldIn, BlockPos p_176460_2_, IBlockState p_176460_3_) { // Replaced this //return p_176460_3_.getValue(field_176463_b) == BlockRedstoneComparator.Mode.SUBTRACT ? Math.max(this.func_176397_f(worldIn, p_176460_2_, p_176460_3_) - this.func_176407_c(worldIn, p_176460_2_, p_176460_3_), 0) : this.func_176397_f(worldIn, p_176460_2_, p_176460_3_); int redstonePowerLevel = this.func_176397_f(worldIn, p_176460_2_, p_176460_3_); int sidePowerLevel = this.func_176407_c(worldIn, p_176460_2_, p_176460_3_); if (p_176460_3_.getValue(field_176463_b) == BlockRedstoneComparator.Mode.COMPARE) { if (sidePowerLevel > redstonePowerLevel) { redstonePowerLevel = 0; } } else { redstonePowerLevel = Math.max(0, redstonePowerLevel - sidePowerLevel); } return redstonePowerLevel; } |
| Comment by Wululululu [ 08/Feb/16 ] |
|
Nope, not fixed. Just tried it in the latest Snapshot 16w05b &16w06a. Still in it. |
| Comment by Kumasasa [ 07/Feb/16 ] |
|
According to |
| Comment by [Mod] redstonehelper [ 14/Oct/15 ] |
|
wululululu: You can add affected versions yourself. |
| Comment by Wululululu [ 14/Oct/15 ] |
|
Confirmed 15w42a |
| Comment by Wululululu [ 17/Sep/15 ] |
|
As you might have guessed. It's still in 15w38a. |
| Comment by Jörn Spannhacke [ 29/Aug/15 ] |
|
This is not just a visual bug, it effects the the output signal! |
| Comment by Wululululu [ 16/Aug/15 ] |
|
15w33c also |
| Comment by Wululululu [ 05/Aug/15 ] |
|
Another week, another version it's in. 15w32a, b, c |
| Comment by Wululululu [ 29/Jul/15 ] |
|
Still in 1.8.8 and 15w31a |
| Comment by Ad Verhoeven [ 30/May/15 ] |
|
This is indeed a block-state bug, I made that clear about 1 year ago with my set of screen-shots. I am not fully sure whether it is going to be fixed easily since it has to do with the time the game takes to calculate these changes. It all seems to be about slight differences in timing, most likely only a few game ticks. I do think that this isn't what is intended to happen, but it might be useful for some redstone machines nonetheless. |
| Comment by Christie N [ 17/Oct/14 ] |
|
Per the screenshot, the blockstate is incorrectly updated. |
| Comment by [Mod] redstonehelper [ 07/Oct/14 ] |
|
Confirmed for 1.8. |
| Comment by Wululululu [ 20/Aug/14 ] |
|
If you look at my first attached pictures to this bug, you'll see that it is very easy to reproduce the visually "on", but redstone signal "off" comparator. It must be a bug and not a feature. |
| Comment by Ad Verhoeven [ 20/Aug/14 ] |
|
the first picture shows how i tried to make a very easy system to demonstrate this bug/feature in a few screenshots, the left side pistons are only to show that there has been a pulse. the third screenshot (which should've shown both pistons extended) however failed, it remained stable. upon removing the repeater i did get the original output i was expecting. screenshot https://bugs.mojang.com/secure/attachment/79165/2014-08-20_12.23.46.png and https://bugs.mojang.com/secure/attachment/79166/2014-08-20_12.23.51.png show what i was expecting to happen (which happens if you do not use repeaters to power the inverter) I hope this information is detailed enough for someone to get hold on this strange bug. |
| Comment by Ad Verhoeven [ 20/Aug/14 ] |
|
I just checked this bug for 14w34c again. those pictures i showed now give slightly different results. the visuals do have effect on the pulse (therefore i think this might actually be a feature??) if the comparator is off it will give a pulse on an downward slope et vice versa for a comparator which is fully lit. the inverter I am using: https://bugs.mojang.com/secure/attachment/30893/2013-06-04_00.58.36.png wow. this is very strange, a repeater used to power this changed it to my previous findings (it only gives a pulse when the comparator isn't lit/on) |
| Comment by user-f2760 (Inactive) [ 24/Jul/14 ] |
|
still an issue in 14w30b |
| Comment by Ad Verhoeven [ 03/Jun/13 ] |
|
first picture i powered the backend first (2 torches side) seccond picture i powered the side first as you can see the power levels are EXACTLY the same, as is the output. but once you combine these with the 2 invertors of the last picture which do not have the same delay you can get short pulses only when the visual of the back 2 torches is turned OFF. (it takes 1 tick more for the redstone block to update the signal after it is pushed) the last 2 give a little last picture of how i implemented everything, i hope i've been clear enough for anyone to reproduce this complicated bug(or is it a feature?). |
| Comment by Ad Verhoeven [ 03/Jun/13 ] |
|
i've found something very remarkable. might be usefull. when i tried to make a up/down edge detector using a sticky piston with redstoneblock and an normal invertor, i found out that it matters which side gets powered first in substraction mode. if i powered the left/right side, the detector would work. if i power the main input of the comparator first, it wouldn't update once the sides got update since the delay between the 2 invertors is too small for the comparator to update its state(the 2 torches stay on while they should turn off). i use 2 repeaters for the inputs, so that the inputs are precisely equal. i will add some pictures. i am not sure if this is a new issue, or just part of the problem in this one(it looks to me as if it could be the same). |
| Comment by GrygrFlzr [ 17/Mar/13 ] |
|
It's fine, |
| Comment by Wululululu [ 17/Mar/13 ] |
|
I didn't find that other issue... sry for duplicating. |