Gravel And Sand Falling Through Piston
If You Put A piston on the fastes movment(Up and down)Like So In The Picture I Think. And You Put sand or gravel on top of it the sand and gravel kinda fall through it. This Dosnt Work with Sticky Pistons.I Have Pics Of That Too (The One Not Falling Through The piston)
Linked Issues
is cloned by1
is duplicated by7
MC-6855Falling Sand glitches through blockDuplicateMC-7380MC Three piston sand doorDuplicateMC-8343Falling Blocks can glitch through other blocks when moved by sticky pistonDuplicateMC-9737Piston pushing non-falling blocks blocks through falling blocksDuplicateMC-26353when i use sticky pistons with a stone ontop, a sand ontop of that and another sand, the blocks get out of orderDuplicateMC-27362Fast-moving pistons can swap sand with solid blockDuplicateMC-51869piston switchDuplicateAttachments16
Created Issue:
Gravel And Sand Falling Through Pistion
If You Put A piston on the fastes movment(Up and down)Like So In The Picture I Think. And You Put sand or gravel on top of it the sand and gravel kinda fall through it. This Dosnt Work with Sticky Pistons.
Attachments16
If You Put A piston on the fastes movment(Up and down)Like So In The Picture I Think. And You Put sand or gravel on top of it the sand and gravel kinda fall through it. This Dosnt Work with Sticky Pistons.I Have Pics Of That Too (The One Not Falling Through The piston)
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
Gravel And Sand Falling Through Pistion
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
relates to
is duplicated by
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is cloned by
Duplicate of MC-4789, please use the search function to see if your bug has already been submitted. Currently over 49% of tickets are being closed as duplicate.
Duplicate of MC-4789, please use the search function to see if your bug has already been submitted. Currently over 53% of tickets are being closed as duplicate.
I this this ticket needs some work. I changed the summary a while back to more closely reflect its duplicates, but it's actually about falling sand breaking into an item when a solid block is pushed into its space, so it has nowhere to go. That's probably intended. I've actually managed to find piston timings that seem to work anyway, and don't require sticky pistons like the previous solution I found. I'm sure someone with more redstone knowledge could make it more compact.
These problems may have been caused by changes to the world alteration code (which [Mojang] Nathan Adams recently rewrote) or changes to falling blocks, as well as changes to pistons. Regardless, I did not say that there have been no changes to the piston code, but that Mojang has not designed the current behavior so much as let it evolve through multiple unfocused changes intended to fix various other bugs.
You say the behavior in MC-51662 is new, but how does it differ from MC-26356 (aside from yours being better written)? What did the sand do before? You say there that "In snapshots up until 14w10c the piston disappears", so when did it actually work?
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.
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).
Ooh, I think I've figured it all out. Watching the behavior of the machine in 14w11b TEST.7z
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 14w11b TEST.7z, 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 PistonVanishTest.7z, 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 PistonVanishTest.7z, 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 14w11b TEST.7z, 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 14w11b TEST.7z 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 PistonVanishTest.7z, 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.
Can confirm.
This can be seen in action here: http://www.youtube.com/watch?v=KLEA3sVaj4o
This is still an issue as of 13w09b.
In addition, player falls through moving piston (piston car elevator)
Added a youtube link
[Mod] Ezekiel (ezfe): My version of this bug (
MC-27362) is completely reproducible in 14w08a.Confirmed for 14w17a
Is this still a concern in the current Minecraft version 1.8.1 Prerelease 3 / Launcher version 1.5.3 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Yes, this still happens in 1.8.1-pre3.
Reopened, thanks.
Is this still an issue in 15w51b ? According to
MC-94432it's not.Sort of. In my test case (
MC-27362) the sand is itemized, which doesn’t make any sense, but is probably better than what happened before. However, I don’t thinkMC-27362is a legit duplicate of this, since it involves a sticky piston and sand swapping with a second block above the piston which isn’t present in this report.Might be fixed in next snapshot, please check
Looks fixed to me.
Confirmed.