Falling sand breaks if a solid block is pushed into its space

Problem is still existing in snapshot 13w11a.

Change the title. 13w01b is history now.

Still broken in 1.5 and 1.5.1 pre-release

This still happens in 1.7.2. You cannot use multiple pistons to push up more than one block at a time or the blocks start to fall back down, even though the pistons are only going up. The top sand/gravel falling back down on a sand/gravel causes it to break because it falls too early.

e.g.

[sand]
[sand]
[piston pushing up]
[sticky piston pushing up]

Top sand breaks before both pistons can be extended.

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 is still a problem in 14w17a and 14w18a. As usual, the OP has LONG since stopped watching this, Mods keep sending duplicates here, but then do not update the affected version list.

There are DOZENS of serious issues going unresolved because original posters don't have the stamina to keep editing the affected versions, those of us who are tracking them can't and the mods won't. These issues are well described, easy to replicate and would take 5 minutes for a mod to confirm in the latest snapshot and update the affected version field. Instead they languish, unassigned and unresolved.

So you're saying that the mods should test all 2000+ unresolved issues every time a snapshot is released? By your own 5 minute estimate, that would take nearly 167 hours, or just short of the 168 hours there are in a week. Snapshots are released approximately once per week, so that would give one person just enough time to test them all, assuming they didn't sleep, eat, or do much of anything other than test bugs.

The point of having a publicly visible bugtracker is to distribute the workload. I do think that there should be a way to allow people to take over an issue if the original reporter has lost interest in maintaining it, or allow multiple people to be set as reporters for one issue. Unfortunately, the latter does not currently appear to be possible in JIRA. Perhaps there should be another user group in between mods and regular users, people who are trusted enough to update certain fields such as affects version/s?

@Torabi, that's a very black and white view you've got there. Actually Christopher Martin is right about something. It's been reported over 1 year already, and the status is still: Community consensus. To my understanding this means nobody from Mojang has tried to recreate this issue since it's been reported. I've updated it several times and have to say the lack of response and action is noticeable. I did read every comment posted on this issue, as a lot of the world we built was based on these mechanics. From one day to the other, all of it was broken without a working alternative. This actually made me stop playing minecraft for quite a while. It's nice that they're adding stuff like pufferfish and pretty flowers, but it seems game mechanics usually aren't on the priority list.

I've started playing again since last weekend after over half a year break, started out in a new world and will build the sand stacker again as soon as I have the redstone to do it (I don't have spawn rights in our multiplayer world) and will update this post with the results.

Community consensus doesn't necessarily mean that nobody from Mojang has tried to reproduce the issue. It typically means that neither Mojang nor a moderator has been able to successfully reproduce the issue, but it's been marked as confirmed rather than "Cannot Reproduce" because multiple people have reported it, or otherwise demonstrated that it is occurring.

In this case, however, I suspect that rather than being unable to reproduce the issue, there's uncertainty about what to do about it. The desired behavior wasn't necessarily intended by Mojang, and wasn't deliberately broken either. It's simply a casualty of other intentional changes to piston timing and falling sand, meant to fix other problems. How can they fix this without breaking something else? When various designs depend on bugs or unintentional behavior, fixing bugs often results in devices breaking.

However, there are still working designs for pushing sand upwards. I don't know if they'll suit your purposes, but this design still works, and here is a very compact version using the same principle.

Thanks for the explanation.

The video's are designs that push sand up but not retract. It did however help me to find this video in which the 2nd design shown is promising and is what I'm looking for including the clock, but I have to find out if it still works in the current version in multiplayer/survival, it is a bit different from what I did before:
https://www.youtube.com/watch?v=62o3FzBpneY

Its purpose and use could be the same as the design I posted, and I think it seems no problem to chainlink it into rows and so can be used for a variety of functions like retractable bridges and stairs like I did have before.. I'll try it and post it here if it worked. Thanks!

Ok guys, it took some tweaking but I've got it to work. Attached is a zip file with screenshots and a text file with a full explanation on what you need, how to lay it out and the repeater clock timer settings. Using this it's suitable to make a retractable sand elevator, but it's also possible to extend it to the back and use it for functions like retractable sand bridges and stairs, etc.

I would like to thank everybody for their contributions and I'd say I'm happy with this working solution in the current minectaft version (multiplayer/survival). Best Regards, FliP

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.

Hi Christopher. I do understand it's not only there for this purpose, but a lot of applications could be replaced by the mechanism provided, timing however is essential. Please try to recreate what I did (file with instructions is attached) and see how that could replace your original workflow for the applications used, I was very surprised to see it work as well as it did after I adjusted the mechanics and timing and because of the mechanism it doesn't need a stop-piston either to keep the piston from moving. The biggest difference is that instead of blocks being pushed, they're being pulled. I understand the original problem is not fixed, but if there's a working workaround I'll gladly adjust my mechanics and use it.

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.

Flip or a mod, can you please add 14w20a and 14w20b to the affected versions list?

Flip or a mod, can you please add 14w21b to the affected versions list?

And now it's June... No recent snapshot, no comments from mods, no programmer feedback, nothing. Reported in January and still unresolved 6 months later.

Snapshots are released approximately once a week, when Mojang has a build worth sharing. There's been no comments because there's nothing to share on this issue. Piston and redstone mechanics aren't the current development focus, and there are currently 155 issues that are at least as many days old, and have at least as many votes.

The 1.8 snapshots have primarily been engine changes (in preparation for the plugin API), bug fixes, and a bunch of commands and features for Adventure Mode. Redstone devices haven't gotten a lot of attention this time around. The interaction between pistons and slime blocks was added because the ZipKrowd crew designed and built the feature themselves, thus meaning Mojang had to spend very little development time on it.

Minecraft is a big, complex game that appeals to a wide variety of people. They have to prioritize and rotate their development focus, and simply cannot please everyone all the time. There are a number of outstanding piston-related bugs, and they'll get looked at sometime in the future, when they have the time to devote to rethinking the mechanics. I want this to get fixed too, but encouraging people to vote for this, and other piston-related issues, would be a more effective strategy than complaining in the comments and pointing out the obvious.

Flip or Mod, can we get an update to the affected versions list? 14w25a and 14w25b.

Torabi, am I to assume from what you are implying that piston mechanics won't be reviewed before the 1.8 release? 1.8 will ship with this bug live? That would be interesting news.

This bug was introduced during the snapshots leading up to 1.5, known as the "Restone Update". That was the last time redstone devices and mechanics were given a significant amount of development attention. It has survived the two subsequent major releases: 1.6, known as "The Horse Update", though most development time was actually spent on the new launcher, and 1.7, "The Update that Changed the World", which focused on world generation, the rendering engine, networking code, and sound system. The current update cycle has focused on more low-level engine work, enhancements to survival gameplay, adventure mode, and commands for use with command blocks. The most recent snapshot (14w25a/b) includes approximately 3 months of work from various members of the team, and it will take some time before all the bugs have been worked out of it.

I don't think it's likely that pistons will see much development attention this cycle – the interaction with slime blocks came as a surprise, and was included primarily because the code was contributed by the ZipKrowd crew. Integrating that into the official codebase would have been an opportunity to review the piston code, but the changes to falling blocks are more likely to blame for this bug than changes to the pistons themselves.

I don't see how 1.8 shipping with this bug is any more significant than 1.6 or 1.7 shipping with it. I find MC-46225 significantly more worrisome, because it results in the destruction of an expensive block, rather than a cheap block such as sand being "broken" into an item entity as described here. Regardless, they will both probably survive the release of 1.8. Redstone users may be passionate, but they only represent a small portion of the Minecraft playerbase.

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 @unknown 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.

Torabi,

Thank you for making the changes. For reference's sake I will answer this in MC-51662 and quote your question there.

Anyone who is impacted by MC-51662 should head over there and vote to make sure it gets resolved.

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.