[MC-6438] Falling sand breaks if a solid block is pushed into its space Created: 06/Jan/13 Updated: 22/Sep/20 Resolved: 22/Sep/20 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Snapshot 13w01b, Snapshot 13w07a, Minecraft 1.5, Snapshot 13w11a, Minecraft 1.5.1, Minecraft 1.7.4, Minecraft 1.7.9, Minecraft 14w17a, Minecraft 14w18a, Minecraft 14w18b, Minecraft 14w19a, Minecraft 14w20a, Minecraft 14w20b, Minecraft 14w21a, Minecraft 14w21b, Minecraft 14w25a, Minecraft 14w25b, 1.14.4 |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Flip | Assignee: | Unassigned |
| Resolution: | Cannot Reproduce | Votes: | 11 |
| Labels: | falling_block, gravel, piston, sand, stacking | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||
| Category: |
Entities
|
||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Normally we'd be able to make sand bridges with pistons pushhing up multiple blocks of sand. You push sand up and just before the block falls you push another block under it and-so-on. But since snapshot 13w01b sand is falling so quickly it breaks when you push another block of sand under it (even with perfect timing). What I expected to happen was...: What actually happened was...: Steps to Reproduce: |
| Comments |
| Comment by John [ 22/Sep/20 ] |
|
Tested 2020-09-22: Fixed/working in 1.16.3 added proofs with the date. |
| Comment by John [ 09/Sep/19 ] |
|
You could create a 2 game tick delay before blocks without support fall. You could modify sand so that if it falls into another block and their is a piston the direction its going it trys to go back the way it came pushing blocks if they don't exceed the pistons range and only braking if it can't make empty space. You could use the several examples provided to find your own fix. It once worked both ways. You could reach under a block before it fell and drag another block under it or push a block under it before it falls. Especially now with observers so we don't need to make self resetting BUD on both sides of the stack I'm fairly sure this would make the most compact scalable counter per input it counts to. |
| Comment by John [ 09/Sep/19 ] |
|
SethBling using this feature in 2012 to make a compact counter |
| Comment by John [ 09/Sep/19 ] |
|
Hard Bump, this is not resolved.... |
| Comment by user-f2760 (Inactive) [ 17/Mar/16 ] |
|
No response for over a year. |
| Comment by Galaxy_2Alex [ 24/Oct/14 ] |
|
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. |
| Comment by Christopher Martin [ 24/Jun/14 ] |
|
Torabi, Thank you for making the changes. For reference's sake I will answer this in Anyone who is impacted by |
| Comment by [Mod] Torabi [ 24/Jun/14 ] |
|
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 dinnerbone 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 Regardless, both are likely caused by one of the following:
I think that falling sand, as an entity, would be pushed by the piston, and only break when landing on a non-solid block. |
| Comment by Christopher Martin [ 22/Jun/14 ] |
|
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 This entire discussion proves my initial point about 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 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. |
| Comment by [Mod] Torabi [ 20/Jun/14 ] |
|
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 |
| Comment by Christopher Martin [ 20/Jun/14 ] |
|
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. |
| Comment by [Mod] Torabi [ 16/Jun/14 ] |
|
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. |
| Comment by Christopher Martin [ 16/Jun/14 ] |
|
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. |
| Comment by Christopher Martin [ 26/May/14 ] |
|
Flip or a mod, can you please add 14w21b to the affected versions list? |
| Comment by Christopher Martin [ 21/May/14 ] |
|
Flip or a mod, can you please add 14w20a and 14w20b to the affected versions list? |
| Comment by Christopher Martin [ 09/May/14 ] |
|
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: 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 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, |
| Comment by Flip [ 09/May/14 ] |
|
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. |
| Comment by Christopher Martin [ 09/May/14 ] |
|
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 "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 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 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 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. |
| Comment by Flip [ 08/May/14 ] |
|
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 |
| Comment by Flip [ 06/May/14 ] |
|
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: 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! |
| Comment by [Mod] Torabi [ 06/May/14 ] |
|
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. |
| Comment by Flip [ 05/May/14 ] |
|
@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. |
| Comment by [Mod] Torabi [ 04/May/14 ] |
|
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? |
| Comment by Christopher Martin [ 30/Apr/14 ] |
|
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. |
| Comment by Christopher Martin [ 19/Mar/14 ] |
|
Hello all. I reported another, similar, fault and was directed to this issue by Galaxy_2Alex. My other issue was 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 |
| Comment by user [ 03/Nov/13 ] |
|
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] Top sand breaks before both pistons can be extended. |
| Comment by Joey Hines [ 19/Mar/13 ] |
|
Still broken in 1.5 and 1.5.1 pre-release |
| Comment by Daniel "Glampkoo" [ 18/Mar/13 ] |
|
Change the title. 13w01b is history now. |
| Comment by Flip [ 18/Mar/13 ] |
|
Problem is still existing in snapshot 13w11a. |
| Comment by Tails [ 17/Mar/13 ] |
|
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. |
| Comment by Flip [ 22/Feb/13 ] |
|
Still the same in the newest snapshot (13w07a). Would really like to have this fixed. We have many bridges and secret entrances that were made using this concept and they're not working anymore and there's no other way I know of to get the same functionality. |
| Comment by Flip [ 24/Jan/13 ] |
|
For more information: http://www.youtube.com/watch?v=U2BFqmS9kr4 This is the same construction, but with a different timed pulse and without the signal shorteners that I've included in the multiplayer screenshots in the attached zipfile. Since 13w01b this is not possible anymore. Blocks will break instead of stack. |
| Comment by Flip [ 07/Jan/13 ] |
|
3 pictures of the sand stacker mechanics. The pictures are labeled part 1 to part 3. If you'd want an even shorter signal (shorten the on period, making the off period longer) add another pulser before part 3 and adjust timing accordingly. I've tried extremely tight timings using several pulsers and still the blocks will break. |
| Comment by [Mod] CubeTheThird [ 07/Jan/13 ] |
|
Can you post a screenshot of this setup? |