Slime Block Retraction Error

Please provide similar screenshots but with the F3 debug screen enabled.

I added 5 screenshots in the order of how it's updated to reproduce this

I also took this to complete vanilla, just in case that would alter any debug information.

@unknown @unknown That's update order shenanigans. When the piston tries to retract the slimeblock, the slimeblock stays stuck at the arm of the other piston. They do retract simultaneously, however due to update order after that piston which wanted to pull the slimeblock, but didn't manage to do so. - I hope this doesn't sound as confusing as it might seem to me when I re-read this.

TLDR: Update order shenanigans, not easy to find a solution for that with the current system (or if ever at all, but let's wait and see 🙂)

They all should retract simultaneously, you are right @unknown, but unlikely to be changed/fixed in the close future.

Would that be MC-11193?

I did find a workaround that isn't quirky, I figured this was something small.
if I don't have the second piston, and I only intend to pull the slime block back, this system works as intended (I was using this for a nether item sorter)

in fact, the extra piston, is technically pointless. but it did not make sense to me, on why a slime block, would prevent a completed circuit, that since it's a solid block, should work just like any other block.
Slime's always been weird. 😃

Thank you for all the lovely bits of information, I'll deal with what I made to work around this!

P.S. No that was not confusing, that makes a lot more sense than what I was thinking the issue was.

@unknown Yes, the random update order comes from there, however, that pistons are update-order-dependent is a bug/behaviour in its own right, I currently don't know if it should better be an own bugpost, rather than resolving it as dupe of MC-11193 (which is related, but influences this piston behaviour).

I'll get back in a bit with a somewhat better-to-see reproduction setup.

@unknown Yes, it's all a big mess, there's a lot to take into consideration, and sometimes there are special cases which don't work as all the other cases before (details would take too long and doesn't contribute much here).

I hope all this gets more orderly at some point. Panda once tried to approach Wire Randomness (and lag) a while back https://www.youtube.com/watch?v=NEMARMNvDsw but it's not that easy, he had to revise himself afterwards https://www.youtube.com/watch?v=NnkSSs-I8XM - his Wire "fix" was just a hack on top of the mess that Mojang has to deal with. It's really awful and not that easy as it may seem, unfortunately.

Here's a maybe somewhat better reproduction setup for the piston thing:

(It's Vanilla, latest snapshot/prerelease; I only used iRed block indicator resource pack for cleaner/better view)

E.g. Repeater/Comparator are atm a way how to control the update order.
If the slimeblock gets updated first it doesn't work, but the other way it does work.

@unknown I got a reply: This bugpost here can be related to MC-11193, it is not a dupe, as this bugpost here is about the update order influencing piston behaviour.

MC-54310 which describes this bug here was resolved as Invalid back in the day, but this may need reconsideration.

Affects 1.16.2 pre-1.

I want to take the opportunity to assume it might not be JUST a piston related issue, since this works without slime (I'll check honey too!)

I'm going to take a hunch here it's not the pistons checking update order. It's the slime block rejecting the retraction maybe due to the piston being moved by something else (separation update might cause the slime block to become immovable?) Wild idea. But maybe its related, and not entirely related to the piston....

My theory is this. to clarify it, that is
There are 3 pistons. the piston MOVING the other piston makes the slime block FAIL to retract (block 36 might be affecting it? not sure)
This is a crazy theory, but MAYBE it's related. I sat and thought about this for a very long time...