Falling sand can replace pistons, destroying them

Still present in 14w10c

Confirmed in my world - No particular orientation noted and random piston loss confirmed.

Confirmed in my world also.

this bug still occures in my worlds (14w06b, 14w10c)
all my pistons with sand or gravel above disappear.
40 days, still no fix? this is the fifth snapshot with this bug

edit: pistons on a solid bloc and pistons in the air are both concerned.

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.

Pistons still disappear in 11b. It varies, sometimes the pistons break, sometimes the sand drops. Either way it should be fixed

Confirmed in 14w11b

yup happens with me too

This problem has been around for nearly 4 months. It's causing havok to many users (even Docm77 mentioned it in a recent youtube video) and this bug is still unassigned... But they had time to futz with the Minecart physics.

Come on Mojang, let's fix some bugs! I have a dozen bugs I am watching that cause major issues for me as a server admin on a daily basis, but instead all Mojang seem to be talking about and focusing on is the name change functionality and plugging all the bugs it's introducing. Oh yeah, and Realms.

OP (Guillem Saldo Rubio), can you please update the affected versions list? This is still around in 14w17a.

This was originally posted in January... and it's still unassigned. Are we to assume then that this will never be addressed?

i thought i should comment on this and say this is still happenning to me in my world. Its sad that mojang hasnt fixed this bug yet.

Nathan,

The OP seems to have given up, and is thus not updating the the affected version field, but if you raise a new ticket with the latest version a Mod just comes along and says "Duplicate!" and closes it, but then fails to update the affected version list with the new versions.

And it's still extant, today, in 14w18a, the ticket is four months old and it STILL is unassigned, but as this is only really affecting redstoner's there's been little movement. Even some of the youtuber's, like Docm77, are starting to grumble about this in their videos.

Updated, whenever it needs an update tell me in the coments so I can update it. (Yes, I read the messages when I get time)

Guillem, will do. I had asked for the update on the 25th and I was getting worried it had been abandoned like so many other issues. I didn't mean to be rude, I am just getting frustrated at Mojang's peculiar inattention to several issues. This issue is over four months old and Mojang is yet to assign it to someone for resolution. Even a single comment: "This is acknowledged, look for a resolution around 14w25a" is more useful than the deafening silence we're currently getting.

When issues like MC-6438 and MC-119 keep rising up like the living dead, over and over again, there needs to be a mechanism for users, other than the original poster, to modify the affected version field. I have made numerous comments on both of those issues for the OP to update them, but to no avail, and lumped this one in with them.

Because of Mojang's small size and relatively level hierarchy, issues are not typically assigned in advance. There's generally a very small window in between an issue being assigned and it being fixed, unless it proves to be very difficult. Because Minecraft is being actively developed, and does not have a stable feature set, they're generally working on large changes, rather than perfecting individual elements. There's not much point in spending a lot of time finely tuning something you may change, rip out, or replace entirely in the next release.

I do think, however, that the accidental destruction of a relatively complex and expensive block such as a piston during its normal operation is a significant bug that should be addressed sooner, rather than later. However, I could not reproduce the issue using the device depicted in the first three pictures. If the pistons are set to 1, 3, or 4 ticks, neither the pistons nor the sand break. Set to 2 ticks, the sand breaks, but none of the pistons did, even after repeated the test 10 times. I was not able to reproduce the issue with the device in the last picture either. Do you have another way to reproduce the issue?

It doesn't happen every time, try 2-3 times then the bug should occur for sure. I used a netherportal for quick chunk unloading, but I guess the tp command should do as well.

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.

I have made a revised world to make it easier to test on unload/load of chunk (attached as PistonVanishTest.7z). The previous world had the test apparatus near spawn, making the behaviour harder to induce due to the delay that spawn chunks take to unload.

There are command blocks to make teleporting back and forth easier. You may need to reload the machine with sand a few times and teleport back and forth a few times, as it seems the sand needs to be at a specific point for it to continue to fall into the piston base. The sand breaking mechanic is much easier to induce. These two facts also seem to indicate a strong link between this bug and the venerable MC-6438.

I have used this machine to re-confirm the bug with 14w19a. Guillem Saldo Rubio, can we get an update to the affected versions, please? It impacts 14w18b as well.

Extremely easy to reproduce with the provided test world. All but one of the pistons were destroyed after teleporting to the spawn and back. Thanks for putting that test world together.

Torabi,

I am glad that it helped, and am happy to put my time into helping make Minecraft better. Please note: your discovery of the sand block breaking from your earlier comment also warrants you marking MC-6438 as confirmed as well, as the one machine confirms both bugs: if you stay close the sand breaks like MC-6438, if you teleport it destroys the piston like MC-46225. If they are linked it's important the same developer is aware of both bugs so they are addressed together, or at least to ensure the fix for MC-46225 does not exacerbate MC-6438, or vice versa.

Your earlier points as to the size and structure of Mojang are well taken. The written word is not a perfect medium and I can be, well, lets say 'terse' and leave it at that. I guess I have two main suggestions and, after saying them, will say no more unless asked for my continued opinion.

Regression Testing - Perhaps Mojang could maintain a typical test world that has one of every redstone and (non-mob) physics mechanic, induced by an appropriate timer and monitored via command block. Prior to a snapshot being released the test world would run for an appropriate period of time before releasing the snapshot. If nothing breaks for 4 hours (as an example), great, release the snapshot. You would, obviously, add new mechanisms each time you add a new mechanic (a great way for end users to see new mechanics in action as an added bonus). This world could be made available for user testing and verification. Heck, the community could even be drafted to help maintain it, though that would effectively mean including the community more in the actual release engineering process. I certainly would pitch in, as was demonstrated by my willingness to build test machines for this and other bugs, and people like the Mindcracker and ZipKrowd would have a stake in helping, too. It would also provide users a way to verify that their local copy of Minecraft is working as expected. If most people can run version x of the regression testing world flawlessly with version x Minecraft, but it doesn't work for a particular user it provides them an avenue of investigation as to why it's working differently than expected.

Prioritisation - I work in IT support, and in a past roll worked in a front line support team. When our numbers of tickets started spiralling out of control we imposed a change embargo on new features until the numbers of new tickets were reigned in. Once it'd settled down we started making changes again. Surgeons stop a patients heart when they're operating on it because working on a moving target is a dangerous proposition. I understand that game development is different in many ways to corporate IT support (and heart surgery), but maybe there are some tools or methods that are transportable that would help manage community ire more effectively.

No-one will be happier than I to see the mod API complete. The lag between new Minecraft release and mods being updated, and the consequent workload for modders, is a huge issue, and I would happily forgo new features for a while to get some some bugs bedded down and the API focussed on after that. The new piston/slime block interaction could have stood to wait, as could have the foray into new minecart physics, as examples, until things were bedded down more, and fighting on many fronts hurts efficiency, so maybe doing less would actually achieve more.

It's just my opinion, so feel free to ignore, but if there is anything of value there please pass it on. If you would like to discuss it further, in another forum, please let me know.

Can Guillem Saldo Rubio or a mod add 14w20a and 14w20b to the affected version list please?

As always, thanks for reminding me to update the version list.