Setup: Place sticky piston with slime-block, a other sticky piston and a other slime block in-front(See attachment 1. Start.png).
Recreate:
Power the first sticky piston (See attachment 2. Powered.png). When Unpowering the first sticky piston, the expected result should be that the piston will pull-back all blocks connected trough slime-blocks (3. Expected.png) but the thing that is happening is (3. Result.png).
Which Isn't logical, Why is a block pulled back by a slime block, but can a slime block that is connected to a block not be pulled back by the block? Cause that same slime block is still sticky towards the block, (I Hope this is explained clearly, English is not my first language).
Attachments
Comments 5
How can it work as intended? when it does not have its sticky property all the time?
Let me give a example: If you would have a peace of gum stuck to a stone and you pull the gum, it will also pull the stone. But when you pull the stone the stone will also pull the gum.
This is the intended behaviour.
It may appear not to be logical at first glance, but I would say that Minecraft logic is often very different from real-world logic. After all, if you trigger a piston with 12 blocks in front, but no blocks behind, why doesn't the piston move backward?
So, keeping this weird kind of Minecraft logic in mind, we did think very carefully about it, but it's something we decided not to do since our design for the new feature was focused on allowing as much flexibility as possible with the new functionality while having one simple set of rules for slime blocks that affect existing functionality as little as possible (designs without slime blocks should actually have not changed at all).
I'll try to explain some of our primary reasons for implementing it the way we did:
1. Allowing non-slime blocks to move attached slime blocks is changing functionality on existing non-slime blocks. This one sounds a bit confusing at first, but maybe think of it this way - should a non-slime block or a normal piston think that it has any reason to move a neighbor that isn't in front of it along it's direction of motion? Looking at it this way can be considered a design decision, but we like to think of the new feature as something belonging only to moving slime blocks rather than applying a generalized idea of "stickiness".
2. Making slime blocks always "sticky" means we limit what we can do with slime block + non-slime block combinations. Once they're stuck together, there's no way to separate them by using pistons. We thought this would be more problematic than useful.
3. If slime blocks are always sticky, how should they behave in front of normal pistons? If they are supposed to always stick, this means normal pistons are effectively sticky pistons when they have a slime block in front. We have to deviate from the stickiness rules and create a special case for normal pistons if we don't want them to stick.
4. If we expand on this idea and say that sticky blocks in general should always be sticky, then the 'logical' extension of this idea is to also say that since sticky pistons are sticky, they should always be sticky. This is the extreme case and there is no way we could implement this ... it would just break too many things since it is a major change to existing behaviour. However, also consider the case if we had decided to implement slime blocks always being sticky, but not implement sticky pistons always being sticky just to avoid this problem - does that seem logical?
I think I've covered most of what we discussed when deciding to only implement it on the slime block - there may be some other things that I don't remember right now, but I hope this is helpful for explaining the reasoning we used.
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. If this has been done, we can reopen the issue.
Keep in mind that the "Resolved"-Status on this ticket just means "Answered", and that we are waiting for further information on whether this issue still exists or not. We will reopen it as soon as the requested information has been delivered.
Works as intended