Sticky pistons no longer dropping blocks if given a short pulse
The Bug
Usually sticky pistons pull blocks back that are placed in front of them. A piston, that is powered using a short pulse, however, leaves its block behind when retracting. This behavior broke in this week's snapshot.
This was an actually intended feature, see: MC-5726.
Speculations
I can imagine that this happend by accident when cleaning the code. It was the case before, that a sticky piston that updated and is no longer powered, would tell the block in front of it to immediately turn from block 36 to its normal block again. Maybe some rewriting changed when that happens, and thus the block now turns into a normal block before the piston starts retracting again.
Linked Issues
Created Issue:
Sticky pistons no longer dropping blocks if given a short pulse
When a sticky piston is given a short pulse it no longer loses the block it is pushing, previously intended behaviour (https://bugs.mojang.com/browse/MC-5726)
When asticky pistonis given a short pulse it no longer loses the block it is pushing, previously intended behaviour (https://bugs.mojang.com/browse/MC-5726)The Bug
Usually sticky pistons pull blocks back that are placed in front of them. A piston, that is powered using a short pulse, however, leaves its block behind when retracting. This behavior broke in this week's snapshot.
This was an actually intended feature, see:MC-5726.Speculations
I can imagine that this happend by accident when cleaning the code. It was the case before, that a sticky piston that updated and is no longer powered, would tell the block in front of it to immediately turn from block 36 to its normal block again. Maybe some rewriting changed when that happens, and thus the block now turns into a normal block before the piston starts retracting again.
is duplicated by
"If you need to drop the block, push a glazed_terracotta, you can only push the block and not pull it."
pretty much what oreo said. This is so much missing the point, that it hurts. It's in the league of suggesting to use normal pistons if we want to drop a block.
Sticky pistons spitting out their blocks is a bug as well! MC-122911
You have basically now exhausted the list of commonly used redstone bugs, can you please give me a build that uses none and behaves differently in 1.12 and 1.13 due to what you describe?
I would like to provide some evidence of the intended nature of the block dropping behavior in case there is some confusion there. Here is the relevant section of code from 1.12.2:
Inside the large if statement are two others. The first checks if the piston has finished extending or not by looking for block 36 2 blocks ahead of the direction the piston is facing. If it find block36, it "drops" the block there (the call to "clearPistonTileEntity" does this). It then sets a flag that causes the next if statement to evaluate false, and that statement is the one that "pulls" the block with the call to "doMove".
The code is very explicitly and intentionally written to drop blocks. It's not accidental as somebody had to expend effort to put this there.
I would like to do the same, against that:
https://www.reddit.com/r/Minecraft/comments/5c752g/help_us_decide_should_observers_update_at_1_or_2/
Then why was
MC-5726marked as WAI? And why has that not been updated if this is intended behaviour? It should be resolved, not working as intended, if this really was intentional.Because https://www.reddit.com/r/Minecraft/comments/5c752g/help_us_decide_should_observers_update_at_1_or_2/d9zmv4l/
Now those changes have been made, back then, intended, now, not anymore.
And on Nov 10th, 2015 _jeb marked
MC-5726WAI. I guess he changed his mind, but it has been codified in the games source code since then in a very explicit and intentional way.user-f2760 This is the full comment of what [Mojang] Jeb (Jens Bergensten) said when the discussion was over (https://www.reddit.com/r/Minecraft/comments/5c752g/help_us_decide_should_observers_update_at_1_or_2/d9zmv4l/)
So, it sounds like "piston leaving block behind" is intended behavior because of its inertia, it is not strictly supported, that a block moves in the new position immediately, tho.
The last sentence is just hypothetically what if they wanted to fix it.
There have been no actual functional changes to the code mentioned above since 2011 so that must clearly not be where this behaviour resided.
Grum, does that mean that the change in behavior is unintended?
I know that this behavior is technically a bug, just like piston translocation was, and as such, we should not depend on or be attached to it. However, almost every single even sightly complicated piston contraption relies on it.This change would put progress in many redstone disciplines, especially slimestone and large doors, back to practically zero. I am normally all for fixing things like piston translocation, that are useful but are still technically bugs, but this behavior is just too important. It is not an exaggeration to say that redstone would be devastated by its removal.
These changes which caused this bug to get fixed are changed so this 'feature' is no longer affected.
So you fixed this bug? Why marking it as invalid rather than "fixed", then?
They reintroduced the bug*
Grum, could you please clear up your statement, it is currently in very indecisive. Is the behavior from previous versions coming back or not?
Wait did you fix it as in re-add pistons spitting out blocks, or did you keep the bug as in and screw over the entire redstone and technical community?
Well, if you at mojang really think that you should make the block retract, think again. You have already changed that dragon eggs can’t break bedrock. People were upset by the change, but they accept it as they saw it like a buggy/glitchy behaviour. But this change, agains something you yourself marked ”Works as intended” will break the majority of piston contraptions. All flying machines will break, and be (almost) unfixable. Alot of piston doors will break, and alot of other contraptions too. This is hurting more than it is helping.
You can’t say that this has always been a bug, and that it was our ”fault” trusting it. But as you marked this as ”working as intended”, you in theory said that we could trust it to stay. If you revert this, you could revert quazi-connectivity. That is ”working as intended”. How can we be sure that this will not change too.
At least you can make a poll or something. Ask the community. At least, you can open this bug report up so people can vote for this issue to get fixed
Resolution: Invalid!? What is it with mojang trying to fix stuff that are not broken?
That doesn't clear it up, is this BUG fixed or not!
To my understanding: the dropping behavior has been reintroduced, but is still considered a bug.
He says that the change that fixed/removed dropping of blocks (dropping of blocks is technically a bug) has been changed so it will not fix/remove it in the next snapshot.
"These changes which caused this bug to get fixed are changed so this 'feature' is no longer affected."
Want to clarify that a bit?
We just did that...
Language is one of the main areas where confusion can be generated the fastest. Please don't refer to block dropping from sticky pistons as a bug in the slightest if its staying in the game. When you call the same phenomenon a bug and a feature in the same sentence, it will confuse hundreds and likely lead to a similar level of outcry as if you had said that you consider the ability of a partial block to hold back water as being both a bug and an unintended feature, especially when it looks like you went through so much effort in the combat update to make water work more like you seemed to have wanted.
Will the feature (the feature which allows pistons to spit out blocks) be re-added in the next snapshot?
I hope this feature comes back in the next snapshot it makes no sense to remove this "bug".
I don't care if this is intended or not, this just breaks WAY TOO MANY things to be changed. Might as well make it Minecraft 2.0.
Dont change Pistons to such a degree please.
The piston dropping its block is not a feature. Nothing in the code supports it being a feature either, this is why when you do changes in other places in the code it suddenly stops working. The behavior from before the snapshot has been restored by fixing another bug (
MC-122711). Do not expect the piston-dropping-a-block to be in the game forever without changes. If you need to drop the block, push a glazed_terracotta, you can only push the block and not pull it.”If you need to drop the block, push a glazed_terracotta, you can only push the block and not pull it” Problem is, this is not possible most of the time. That is completely ridiculous to even suggest that this behaviour could be compensated by something like that. I would say that in 95% of the cases glazed terracotta cannot do the same thing as sticky piston block dropping. This is becouse most contraptions are designed to be reusable, and you need a second piston pushing the terracotta in place.
One thing you can rely on, is that the community will rely on this behaviour to stay, and use it accordingly. It is just too important and way too useful to not to use.
I would say that this behaviour is the single most important bug for redstone, much more important than quasiconnectivity. We could propanbly do about 50% of the things possible with quasiconnectivity without quasiconnectivity, but if this gets fixed, i would say that at least 80% of all redstone ever made that uses sticky pistons will be broken, beyond repair. Note that this does not only mean all piston doors, all treefarms and all flying machines, but simple binary counters, simple logic gates based on observers and sticky pistons, and overall basically everything that uses sticky pistons.
If there are three things that are important for Java redstone, they are (in my opinion, and in order)
1. Sticky piston block dropping, since this behaviour is so fundemental in the redstone system as we know it, i would estimate that more than 75% of all redstone ever made would be broken without it, which of at least half would be broken beyond repair, offering no alternative.
2. Quasiconnectivity, since this again is something fundemental that a lot of contraptions are based on. If this gets fixed, i would estimate that about 50% of all redstone would be broken without it, which of about 50% would be broken beyond repair.
3. Deterministic update order, at least to some extent. This allows for so many intresting bugs and quirks to be discovered and used reliably
Sorry for the wall of text, and i hope you get my point. This behaviour is too important to fix. If this gets fixed, not only the tech community will be screwed up, but also everyone who has ever made anything that uses sticky pistons, that is the whole redstone community. The broken contraptions are counted with 8 or more digits. If it gets fixed we can just move to bedrock edition, no point in playing java any longer. I would seriously suggest making it an offical feature. It is just way too important to be broken.
Grum, what you are saying here is literal BS. You are saying it is okay to break every redstone contraption involving pistons. That is literally holding up a neon sign asking all redstoners to quit. Suffice to say, I definitely won't be using 1.13, and I'm not the only one either.
Just made an account on bugtracker to say that this thing will literally push the "motor" part of community away from MC. That will cause to less MC related YT and info content in future and drop MC to dust just like an unwanted kids toy.
Please keep the this feature in the game would be a shame to see it go!
Alright grum, I respect the work you do on the daily, I truly do, but this is not ok and makes no sense to fix.
I will be deconstructing some false founded arguments that you and others have used against things like QC and bd.
"This isn't a feature therefor you shouldn't have been using it"
This argument can be deconstructed to a simple counter arguments that completely make this argument useless. This behavior has been in the game ever since pistons were added, if this was a bug, you should've fixed it then. Not now when everyone riles on it. You have no right to complain about people using this to their advantage.
"If you need to drop the block push a glazed terracota"
This is evidence of what others and I have been saying for a while. That you do not understand these "bugs" enough to make a call on them yourself. If you know anything about redstone you know the whole point of this "block dropping" is to be able to pull the sucker back in, something incapable of doing with glazed terracota. You're argument is the same as saying "just use a regular piston". It makes no sense.
"It's not intuitive"
From a game design perspective, making something un-intuitive when done right can be a stroke of genius and excite the game play experience for a user.
If everything in the real world always worked the way you expected then we can all agree that would be a dull life. Having these "quirks" in your game make the game more adaptable to real life methods and scenarios.
Grum I really appreciate the work you and others at Mojang are doing, but these past few updates are quite possibly some of the most dumbfounded "bug fixes" to ever exist.
You seem to have a real disconnect to the bugs that you are fixing that benefits nobody and harms us tech players. I think it would be ideal for you to have a line of communication between the tech community. I'm not having a go but I've seen you and other devs constantly back out of conversations about these things once you've run out of arguments. You have no valid reasoning for doing the things you are doing and having you in an environment where ghosting on a reddit comment would be so amazing for everyone. Again, I might sound threatening and that's truly not my intention, my intention is to have a civil discussion with you, that way we can arrive at a conclusion that benefits everyone.
Final reply: sticky pistons dropping off blocks will return in the next snapshot; but is not guarenteed to stay forever.
Please take any further discussion to the r/mojira subreddit.
This really did need to change they can add a new type of piston for more features if needed and terracotta blocks are a thing people.
[Mojang] Grum (Erik Broes) This is also very controversial, but if you actually intend to have a feature in the game, that replaces this "bug", glazed terracotta is not the way to go, for reasons others already mentioned above.
However, a kind of replacement could be introducing a sort of slippery piston. The slippery piston always can only do one action, no matter what pulse length it receives. You could realize that by having a block state for that piston that stores information about whether it has pushed a block the last time or not.
Again, please take any further fiscussion to r/mojira.
Solution: Add Honey Pistons