mojira.dev
MC-54686

Pistons Not Updating Under Certain Circumstances

This bug causes pistons to be turned on when a redstone pulse begins but fail to be turned off due to lack of a block update when it ends. It occurs when a piston is below a line of blocks with redstone on top of them, the line is sufficiently long, and the redstone signal is generated sufficiently far away. Both definitions of 'sufficiently' seem to depend on one another, on the direction of the piston, and on whether the blocks were created via /clone.

This was tested only in creative mode.

What I expected to happen was...:
Piston turns on when redstone is turned on and turns off when redstone is turned off.

What actually happened was...:
Piston turns on when redstone is turned on and does not turn off until redstone is turned off AND piston is manually updated.

Steps to Reproduce:
1. Create a line of 6 solid blocks.
2. Place redstone on top of all of them.
3. Place a piston beneath the northmost one (if the line is north-south) or the westmost one (if the line is east-west) with its head to extend perpendicular to the line of the redstone.
4. Place a redstone block above or next to the redstone on either of the two blocks at the end of the line farthest for the piston (only the farthest block works if the line is east-west), then destroy it. The piston will extend but not retract.

I think I had at least one test each where a south-end or east-end piston had the glitch, but I have no idea how to reproduce this.

If only 5 blocks with redstone are used in a north-south line, the piston will behave as normal when a redstone block is used to power the end of the line farthest from the piston, even though powering this same piece of redstone with a 6-block line caused the bug to occur.

If the 6-block north-south line is /clone'd, only the farthest piece of redstone on the new copy will cause the glitch when powered, rather than the last two as when the block is placed manually.

if the piston head faces off the end rather than perpendicular to the line, the line must be 8 blocks long for the glitch to occur, and only the farthest piece of redstone may be powered.

If the piston head faces back along the length of the block line, no number of blocks below 16 (the point at which power from the farthest block no longer reaches the piston) will trigger the glitch.

If you create a 3-block north-south line, then place another block with redstone on it up and to the west of the farthest block in your line, then place two more blocks with redstone to the south of the block you just placed, powering the redstone on the last block in that sequence will trigger the glitch.

And probably quite a few other permutations I haven't found yet. The fact that the piston must be below the line and on either the westmost or northmost part of it suggests to me that the glitch is related to the order in which blocks are powered by redstone in the same tick (as seen when using command blocks with /fill-based clocks), but I could be completely off base.

Attached is an image of a few of the configurations that do and don't yield the bug. Please excuse the sloppy formatting and poorly drawn arrows.

Related issues

Attachments

Comments

migrated
[media]
migrated

Duplicate of MC-108

migrated

@Blah: Isn't that just a report on quasiconnectivity? This seems like a distinct issue, since the piston is being powered directly rather than indirectly and is still not receiving some updates.

Panda4994

@HexGrain
Let me try to explain why it was marked as duplicate to quasi connectivity.
To clarify that: I find it discussable whether is should be marked as duplicate or not as it is not only caused by quasi connectivity.

The problem you noticed there is dependent on the order in which the redstone line turns off.
This order is dependent on a few things. (for example: where was the power source or how many redstone are connected and also the state of internal data structures)
In total it adds up the an order which will look pretty much random to us. So don't try to find all permutations for this behavior. It isn't possible 😉

Now the piston will only retract when, at the time the redstone on top turns off, all quasi connectivity blocks are unpowered already.
If an other order is picked the piston will stay extended because of the quasi connectivity. When then the quasi connectivity block gets turned off it doesn't update the piston. (as it is probably described in the post about it)

And that's how you end up with the extended piston there.

Now as it's unlikely to be fixed in the near future as it's really basic redstone behavior I at least want to give you an workaround.

Try to use half slabs instead of full blocks there. Slabs don't cause the quasi connectivity as they can't be powered. So no matter when the block on top of the piston turns of it will always be able to retract already.

migrated

@Panda: Thanks, that makes sense.

migrated

Duplicate of MC-11193

migrated

(Unassigned)

Unconfirmed

redstone

Minecraft 14w18b

Retrieved