MC-51662Sand/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.
Environment
Java 1.7.0_55 on Windows 8.1 x64
Java 1.8.0_11 B12 on Windows 8.1 x64
Linked Issues
is duplicated by2
Created Issue:
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 behavior. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually.
Please note, this may be related to bug
MC-46225, but this is new behavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.Environment
Java 1.7.0_51-b13 on Windows 8.1 x64
Attachments5
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 behavior. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually.
Please note, this may be related to bug
MC-46225, but this isnewbehavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.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 behavior. 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 ravel 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 behavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.
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 behavior. 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 behavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.
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 behavior. 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 behavior. 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 with not manifest until you change the repeaters to the first setting. On that setting the behavior of sticky and non-sticky pistons is identical.
duplicates
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 behavior. 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 behavior. 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 wi
thnot manifest until you change the repeaters to the first setting. On that setting the behavior of sticky and non-sticky pistons is identical.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.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
is duplicated by
relates to
duplicates
relates to
is duplicated by
Java 1.7.0_51-b13 on Windows 8.1 x64
Java 1.7.0_55 on Windows 8.1 x64
Java 1.8.0_11 B12 on Windows 8.1 x64
is duplicated by
I can confirm it's still an extant problem. I fixed our server's witch farms about 4 times until I realised what was happening. Confirmed in 14w10c.
Mojang may have tried to fix it in 14w11a or 14w11b: the piston no longer disappears in 14w11b. However, the sand/gravel now breaks into entities in the same way falling sand/gravel is broken by a torch. I have reported this new behavior as bug MC-51662.
Hello all. I reported another, similar, fault and was directed to this issue by Galaxy_2Alex. My other issue was MC-51662, if you're interested. I raised it as I thought my issue was discreet from this one as my demo machine doesn't stack blocks (and is significantly simpler), but it does break sand/gravel in a similar fashion. Can the original poster please attach a world download so we can confirm if this bug is still present in 14w11b? I would also like help confirming whether or not my issue is actually the same as this one.
Edit: I have looked at the demo video and rebuilt the machine and I think this is a case of mistaken identity. This machine, like my demo machine in my report seems to be demonstrating a new bug. What it looks like is that falling sand gravel falling onto a piston head block in the process of extending or retracting is being treated like falling onto redstone/torches/etc and breaking the block. I can confirm I have tested the behavior in both 1.7.5 and 14w11b and the fault occurs in both. I will attach 1.7.5 and 14w11b worlds to this issue, I guess, as my issue has been closed.
Further Edit: I recreated my demo machine in 1.7.5 and that clearly shows that, while the issues are similar, the issue MC-6438 is current in both 1.7.5 and 14w11b, and my issue (MC-51662) is not present in 1.7.5 but is present in 14w11b. I would suggest this means they are similar but different issues. I am attaching demo worlds now.
This bug used to happen while in proximity of pistons up until 14w08a, or there about. After that, is takes an unload/reload to exhibit the behaviour.
The peculiar behaviour of the block breaking, being unpredictable at 1, 3 and 4 ticks, but completely predictable at 2 does suggest the it is related to falling timing. Either this bug is related to MC-6438, or MC-46225 AND MC-6438 were resolved pre-1.7, as the bug history would suggest, and this behaviour is a new bug and MC-6438 and MC-46225 were re-opened by mistake.
These are impacting a wide range of users. I have heard Youtuber's refer to it. The Mindcrack server was updated to snapshots circa 14w08a, and since then DOCM77 has occasionally mentioned he's constantly repairing his Witch Farm, which is how I discovered it: I would come back to the witch farm and it would be covered in witches and the shifting floor would only be partly working. With a bit of investigation, either the sand would be missing, or the piston. And, after repairing and leaving and coming back, some of the same pistons would be gone, but not all, and some new ones. There didn't seem to be a predictable pattern.
Please help! This is a show-stopper for ANY machine using pulse shorten-ers, and it's not like those are uncommon.
EDIT - It's definitely a moving target. I checked back over my notes and bug history, and found that I initially only saw the piston breaking mechanic and started watching MC-46225. Later I found that the issue seemed to have evolved (between 14w10c and 14w11b) and reported it as MC-51662 and was from there referred to MC-6438.
It's all very confusing, and as months have passed since I started watching these issues I am having trouble keeping the order of events straight.
Flip, et al.
The sand bridge is not the ONLY implementation where this is broken. In the case of Pulse Shorten-ers we can't change the activation rate to prevent the sand block breaking.
The problem here is that I think this is a new bug that the Mods are claiming are two old bugs. I refer to my most recent post on MC-46225:
"The peculiar behaviour of the block breaking, being unpredictable at 1, 3 and 4 ticks, but completely predictable at 2 does suggest the it is related to falling timing. Either this bug is related to MC-6438, or MC-46225 AND MC-6438 were resolved pre-1.7, as the bug history would suggest, and this behaviour is a new bug and MC-6438 and MC-46225 we re-opened by mistake.
These are impacting a wide range of users. I have heard Youtuber's refer to it. The Mindcrack server was updated to snapshots circa 14w08a, and since then DOCM77 has occasionally mentioned he's constantly repairing his Witch Farm, which is how I discovered it: I would come back to the witch farm and it would be covered in witches and the shifting floor would only be partly working. With a bit of investigation, either the sand would be missing, or the piston. And, after repairing and leaving and coming back, some of the same pistons would be gone, but not all, and some new ones. There didn't seem to be a predictable pattern.
Please help! This is a show-stopper for ANY machine using pulse shorten-ers, and it's not like those are uncommon."
Either the two bugs have merged into one bug, or MC-6438 and MC-46225 were resolved as stated and there is a new, discreet, bug. The machine in MC-46225 would seem to demonstrate this, in that one action produces both the results, and the distinction between the two results is on unload and reload of the containing chunk. The timing peculiarity demonstrated by that machine (two ticks making the sand breaking VERY predictable) would also seem to indicate that. Then again, I am not a coder, but it does indicate that it needs investigation by someone who IS.
EDIT - It's definitely a moving target. I checked back over my notes and bug history, and found that I initially only saw the piston breaking mechanic and started watching MC-46225. Later I found that the issue seemed to have evolved (between 14w10c and 14w11b) and reported it as MC-51662 and was from there referred to MC-6438.
It's all very confusing, and as months have passed since I started watching these issues I am having trouble keeping the order of events straight.
Flip,
I am not meaning to hijack you bug, but I was sent here when a mod marked my bug report (NOT about sand stacking specifically but about sand breaking generally: MC-51662) as a duplicate of this one. At that point I was forced to start commenting here to have any hope of having the major bug I am experiencing fixed. It's a frustrating situation. I felt then, as now, that my bug may (I emphasise MAY) be a related but distinct issue, as yours relates to pushing sand under falling sand, where as my bug was just about pushing sand up on a piston. Either way, I'd like to see it fixed.
If you refer to a standard witch farm design, as shown in http://www.youtube.com/watch?v=RGynJ0yOhmA, this bug will result in 14w04c to 14w19a. You can see in MC-46225 that this bug has evolved and is spilling over into many applications, as the machine designed to expose the piston vanishing bug will also reveal the sand breaking issue.
And, sand is STILL breaking in 14w19a and we can't get a fix (could you please update the affected versions field please?). It's been months, MC-46225 is also still un-addressed and it seems that (in absence of evidence to the contrary) it no-one at Mojang even has it on their radar. ANY redstone machine that uses piston/sand combos as a pulse shortener experiences this if it's receiving rapid pulses. There is no replacement for the sand/piston shortener because it relies on the sand falling mechanic to prevent single tick pulses from resulting in a pushed out block. Combined with a tripwire hook and you have an unjammable device (see the above video for the explanation of the tripwire hook/ falling sand unjam mechanic). There is no workaround because the intrinsic mechanism is what's broken.
Torabi,
This is where this gets frustrating. The behaviour I am discussing is new to the 14w branch. The machines I discuss work in 1.6 and 1.7 (being witch farms based on shifting floor design) and are only breaking recently. This contradicts your statement about there being no changes to piston mechanics.
I will re-iterate from the beginning:
I did not report MC-6438. I was directed here after my issue (MC-51662) was marked as being a duplicate of this one. My bug was NOT about pushing sand under sand (an esoteric, rarely used redstone mechanic), but merely the destruction of sand by upward extending piston heads. MC-6438 has a very generic sounding title, but when you read the bug description it is a very narrow application, and has many more moving parts than what I discuss in MC-51662.
This entire discussion proves my initial point about MC-51662 being a distinct bug. MC-6438 has existed for a very long time, but the behaviour reported in MC-51662 only just showed up in the 14w branch.
I would suggest that many people, the ZipKrowd none-the-least, will be interested to hear that their witch farms, which work fine in 1.7, will cease to work as of 1.8, especially if MC-46225 also remains un-addressed.
Lastly, as to your comment about this being a 'low cost' bug, I disagree. All of the components of pistons are farmable, and are therefore renewable. Sand is not. New lands must be explored to find sand. From a certain point of view, sand and gravel are are more valuable than pistons.
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.
Relinking to MC-51662 because of the better description.
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.
Copying over the relevant section of my comment on MC-51662:
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.
If you read the comments of MC-51662 and MC-46225 you'll see the actual bugs don't derive from the piston but from the falling sand; the piston is just a method to induce the behaviour. In the case of MC-46225, sand can fall into a piston, replacing it which effectively destroys the piston. If you add any block under falling sand at the right instant the sand would fall through it, too, if my understanding is correct. I've seen falling sand fall through pistons and then part way into the floor below on 14w10c. It's like it's got acid for blood 
My point was there has been recent jiggering (between 1.7.2 and 14w08a) with the falling sand mechanics (which lead to MC-51662 and MC-46225) and this issue may have arisen from that jiggering. How recently did you move to snapshots? Could the issue have been around since earlier snapshots and you didn't notice until recently? There has been subsequent jiggering which has evolved MC-51662 and MC-46225 over time. This is likely the changes to the tick processing for block updates, or other recoding around the Mojang's efforts at making MC more efficient.
Falling sand is a different object to sand at rest, IIRC, so there may have been other code changed recently that's delaying the transition from falling sand to stationary sand. Is the behaviour the same for gravel and all other gravity affected blocks? Just wondering if it's a property of the falling mechanic or of sand itself.
Dupe of MC-51662
Duplicate of
MC-6438If 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.
I'm not sure this is the same issue.
MC-6438refers 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 intoMC-6438and try and see if it does encompass this.Reworking
MC-6438to be a separate issue.In response to Torabi and continuing from the old
MC-6438conversation:"You say the behavior in
MC-51662is new, but how does it differ fromMC-26356(aside from yours being better written)?", TorabiAll 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-46225started breaking the machines. Then, from 14w11b machines were breaking because of bothMC-46225andMC-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 inMC-46225or 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).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.
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-46225andMC-26356(which turns out to be a separate issue), and now understand the difference in behavior that causesMC-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 (
, on Minecraft 1.7.9, probably for this reason. I see the falling sand intersecting the piston head even on the slower repeater settings.
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.7zHowever, 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: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.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.
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..
I'm getting slightly different results in 14w34d than in previous tests. Not much has changed with the 14w11b TEST.7z
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 PistonVanishTest.7z
, 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.
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.
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.
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.
Confirmed for
MC-89030Christopher Martin, please retest this. [Mojang] Grum (Erik Broes) 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.
Let's hope so!