[MC-51662] Sand/Gravel broken into entity by upward extending piston

Pistons extending upwards break sand and gravel the same way a torch breaks falling sand and gravel.

I have included a world download with a machine to demo the behaviour. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually. To start the machine, load sand or gravel on the pistons and press the stone button.

Please note, this may be (or may not be) related to bug MC-46225, but this is different behaviour. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.

Further info - if you replace the pistons with sticky pistons in the test world attached, the problem will not manifest until you change the repeaters to the first setting. On that setting the behaviour of sticky and non-sticky pistons is identical.

Linked issues

is duplicated by 2

MC-11001 Sticky/Normal piston destroying sand/gravel block Resolved

MC-79789 pistons seem to have issue with sand blocks Resolved

relates to 1

MC-46225 Falling sand can replace pistons, destroying them Resolved

Attachments

14w11b TEST.7z

PistonVanishTest.7z

PistonVanishTest-18pre2.7z

Comments 15

galaxy_2alex 2014-03-19T08:29:52Z

Duplicate of MC-6438
If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.

Christopher Martin 2014-03-19T09:35:02Z

I'm not sure this is the same issue. MC-6438 refers to pushing blocks into a stack. The problem shown above occurs with a single block placed on a piston, and happens quite predictably on a slow cycle, not spamming. I will look into MC-6438 and try and see if it does encompass this.

Torabi 2014-06-24T05:16:06Z

Reworking MC-6438 to be a separate issue.

Christopher Martin 2014-06-24T09:24:44Z

In response to Torabi and continuing from the old MC-6438 conversation:

"You say the behavior in MC-51662 is new, but how does it differ from MC-26356 (aside from yours being better written)?", Torabi

All tick variations now seem to break blocks (not just 2 as in MC-26356). Shorter ticks seem to result in more pulses, resulting in a higher chance of the block breaking, but all tick lengths, when spammed, break blocks.

"What did the sand do before?", Torabi

It didn't break. In the latest 1.7 version witch farms work all day without issue.

"You say there that "In snapshots up until 14w10c the piston disappears", so when did it actually work?", Torabi

It worked in every release of 1.7 before the 14w branch, and in all versions of 1.7 after the fork. From 14w04a MC-46225 started breaking the machines. Then, from 14w11b machines were breaking because of both MC-46225 and MC-51662.

Unfortunately, this issue is now four months old for me, so my imperfect memory is now a complication. The description should likely read:

"In snapshots up until 14w10c the piston disappears (as in MC-46225), but from 14w11b the piston now can display either behaviour, either disappearing as in MC-46225 or breaking sand as described above."

If that makes sense to you I will update the description.

Also, the behaviour has evolved over the snapshots. In 14w11b the blocks break aggressively while you are present, now it takes a two tick pulse to do it in front of you, but a chunk unload, by teleporting away or portal travel, triggers it (or MC-46225) fairly predictably (as long as you are aware of the spawn chunks and take their impact into account) no matter the pulse length.

Really, the best bet at this stage is to download the machine from MC-46225 (it has many improvements so I'll post it here too and remove the old one) and load it into 14w11b and step forward from there, as the behaviour seemed to subtly evolve over time. If you need me to do that process it will have to wait until the weekend for me to have enough time to dedicate to that sort of testing.

As of 14w25b, it is much more likely for the sand to break than piston disappear. I can't even get pistons to disappear in the test world on SP any more, but if I download our server files to a local test server and run them in 14w25b they do disappear on chunk unloads, but not at the same rate they used to (circa 14w10c).

"Regardless, both are likely caused by one of the following:
Sand falling onto a moving (extending or retracting) piston head, treating it like a non-solid block (such as a torch, rail, etc) and breaking.
Sand falling into an extending/extended piston head (MC-4789) and breaking because it has nowhere to land (MC-6438).
Sand falling into the empty space while the piston is retracted, and breaking rather than being pushed when it extends.
I think that falling sand, as an entity, would be pushed by the piston, and only break when landing on a non-solid block.", Torabi

I concur that all of these are possibly related. It needs a serious investigation to straighten it out. There may be an underlying tick processing issue, as was recently demonstrated by Panda in reference to Redstone Torch processing (MC-56541).

Christopher Martin 2014-06-24T09:29:20Z

I have uploaded PistonVanishTest.7z, a revised version of my original test machine for these issues. Please use it for testing as it has the machine built outside the spawn chunks, ensuring chunk unloads on teleport. It also have signs explaining it's use and command blocks for teleport testing. I will revise it this weekend with command blocks to manipulate the tick rates to allow that sort of testing as well, but I need to research the commands for doing that and make sure my understanding is firm before I try updating this.

5 more comments

Torabi 2014-06-25T00:33:45Z

Ooh, I think I've figured it all out. Watching the behavior of the machine in

[media]

on 1.7.9 and comparing to the behavior in 14w25b was very enlightening. I think I now know what causes MC-46225 and MC-26356 (which turns out to be a separate issue), and now understand the difference in behavior that causes MC-51662, though I'm not sure which component is causing the issue. However, I strongly suspect it's the behavior of the FallingSand entity, rather than the pistons.

What's baffling to me is that I get completely different behavior from the falling sand between the two test worlds (with the repeaters set to the same delay), testing on the same version of Minecraft.

Minecraft 1.7.9: In

[media]

, with the repeaters set to 1 tick, the falling sand is pushed up by the extending piston head, and goes up and down very quickly, and pretty reliably breaks into an item after 30 seconds. What's noteworthy is that it never bounces fully back up into its original position, and never turns back into a block, rather than an entity. You can see this by keeping your mouse cursor on the falling sand – if you can see the block selection border, then you're pointing at a block. And according to the wiki, FallingSand will self-destruct if it lives for more than 600 ticks – or 30 seconds. This is (at least one) cause of MC-26356.

However, in

[media]

, still on Minecraft 1.7.9, the falling sand does appear to jump up to its original position, and turn back into a block, even with the repeaters set to one tick. I also see the sand occasionally intersecting the piston head. The motion of the sand is jerky, not smoothly following the piston head. The sand breaks at random, often in less than 30 seconds. I'm not sure why they break in this situation, though I suspect it's because they're falling through the moving piston head (MC-4789), trying to revert to a block, and breaking themselves instead because the block is already occupied. In fact, I'm finding that the sand breaks very quickly on any delay setting in

[media]

, on Minecraft 1.7.9, probably for this reason. I see the falling sand intersecting the piston head even on the slower repeater settings.

However, back in

[media]

, the sand bounces smoothly with the repeaters set to any setting other than 1, following the motion of the piston head without ever intersecting it.

Minecraft 14w25b: The behavior of In

[media]

appears identical to its behavior in 1.7.9, except the sand breaks almost instantly if the repeaters are set to 2 ticks. I can't get the sand to break on 3 or 4 ticks. This may be because the device is in the spawnchunk area.

As for

[media]

, I'm getting the same behavior as on 1.7.9: almost instant breakage on any delay setting other than 1 tick, and they don't last much longer on 1 tick.

I suspect that this is a race condition, that whether the sand breaks depends on whether it updates before or after the piston does. Things like loading chunks, monsters spawning, or tabbing in and out of the game window seem to disrupt the timings, causing the sand to fall further and break. I've still yet to see sand replace a piston, though I'm guessing that's a bug in checking block IDs versus metadata, like MC-4239. Considering this little tidbit from the wiki:

If the block at its location has the same ID as its TileID when Time ticks from 0 to 1, the block will instead be deleted, and the entity will continue to fall, having overwritten it. (This was the result of Mojang's failed attempt to "fix" infinite sand/gravel/dragon egg/anvil/etc. generators by trying to have the falling sand entity delete the duplicated block the next tick)

I'm guessing that block check in the FallingSand entity is misreading the piston as sand, and thus deleting the piston base if the FallingSand entity ever occupies the same block.

Basically, I think all these issues (other than MC-26356) are caused by FallingSand not really being solid – it can fall through blocks and intersect them. Pistons are capable of pushing it because they can push entities. If the FallingSand gets to update first, it falls into the piston head and breaks. If the piston updates first, it pushes the FallingSand entity upwards.

Christopher Martin 2014-06-25T05:02:41Z

Thank you for that comprehensive testing and fault description. I appreciate the attention you are giving this issue.

You have explained something that had been confusing me: a conflicting set of results. I had been using the two machines interchangeably, assuming that they would produce similar results, but of course they do not. I am... amazed. That inconsistency hints at complexity behind the scenes, and indeed you seem to have hit the nail on the head: there are multiple interactions producing unexpectedly complex results.

If I (vaguely) remember correctly there were some posts on YouTube about new sand/gravel generators (DocM77 may even have done one) in the 14w branch, but as I don't use pure exploits I didn't look into their mechanics at all at the time. Part of bug either may be related to the re-emergence of these generators, or perhaps as a result of attempts to close the loophole again.

When I get home from work I'll have a dig around online and see if any of the new sand generators use mechanics seen in the demonstration machines above.

Christopher Martin 2014-08-13T22:51:41Z

The bug still impacts 14w33a, however the scope is reduced. Setting the test loop repeaters on the test machine to two ticks will cause the blocks to break on travel to and from the nether (chunk unloads I suspect) on about one in five trips. It will also happen with the repeaters on one tick, but much less frequently than it use to, and again only when the chunk is unloaded and then loaded again..

Torabi 2014-08-20T14:51:42Z

I'm getting slightly different results in 14w34d than in previous tests. Not much has changed with the

[media]

world, except the sand now breaks almost instantly with the repeaters set to 1 or 2 ticks. I still cannot get it to break on 3 or 4 ticks. In

[media]

, however, I now cannot get it to break the sand on 1 tick, and it only breaks on 2 ticks if I travel through a portal. 3 or 4 ticks still causes the sand to break almost instantly.

Whether the piston breaks the sand into an item is still highly dependent on external factors that influence timing, and therefore the behavior is unpredictable and unreliable. The piston should always push the fallingsand entity up, at which point it can turn back into a block in the space above the extended piston head. The fallingsand entity should not attempt to revert to a block in the space occupied by the piston head, and should not turn into an item if the space is occupied by a piston head, but should instead remain as a fallingsand entity.

Christopher Martin 2014-08-26T10:56:17Z

I have uploaded a revised version of the test world. There is a setup now to move the player between the test site and a remote chunk, forcing the repeated load and unload of the chunk.

Sonicwave 2014-10-12T22:20:45Z

Confirmed (1.8). Can reproduce by placing a lever next to an upwards-extending piston with sand on top of it and holding right-click on the lever for a while.

Christopher Martin 2014-10-14T00:10:35Z

Sonicwave,

This is never getting fixed, unfortunately. It's been six months and there has been no official word from Mojang. I certainly won't be updating the ticket any more: I just can't keep investing my time in it. It took a monumental effort to even get a Mod to acknowledge this was a discrete bug, and that was a good three months prior to 1.8's release, plenty of time for Mojang to address it. It remains unassigned, so we can be sure of one thing: no-one is looking at it. And seeing as there are many bugs going back multiple versions that remain un-addressed, it seems this bug, like so many before it, aren't 'sexy' enough for Mojang to be bothered to fix it (there was plenty of time to add feature after feature to 1.8, but bug fixes are boring, it seems).

It's insulting to me to have spent twenty times the effort and time it would take to fix the bug updating tickets for each new snapshot, constantly re-testing because, as yet, I can't even be sure anyone at Mojang knows about the bug because there has been no official notice. And, while many people have sent me PMs about this, replied and commented on my YouTube videos about this, no-one up-votes the ticket, so it languishes here, un-addressed and without even a plan to acknowledge it, let alone fix it.

So, I am pretty much done with this bug now. And I may be done with Minecraft too: I paid for a product and it doesn't work to my satisfaction and the manufacturer has done nothing to resolve my issue. If I am willing to take that sort of treatment that just makes me a sucker. I want a refund.

marcono1234 2015-12-11T21:02:45Z

Confirmed for

15w50a Currently mainly caused by MC-89030

Torabi 2016-10-08T14:46:14Z

@unknown, please retest this. @unknown has done a considerable amount of work on pistons within the past few snapshots, and I am no longer able to get the falling blocks to break in any of my tests. I'm hoping this is fixed, but would like confirmation from others who have successfully replicated it in the past.

Torabi 2016-10-16T12:29:10Z

Nothing wrong with pistons anymore ever. -Grumm

Let's hope so!