Pistons Translocation glitch

Possibly a duplicate of, or related to MC-108418

doesn't relate to MC-89030. powering a melon farm with short pulses never was a good idea. There are literally hundreds of working melon farm designs.

however, it still counts as a bug as it launched the melons backwards. And that counting as a bug matters.

ilmango, replying to your comment at http://prntscr.com/csbl71
actually im not sure its a big change of behavior of stopping a bug that they thought they stopped, and either way they would of found it. This is different from other piston trans. glitches, as this one counts for items while fixed. and nobody else uses this glitch as most of them dont even know they EXIST (the item ones AFTER FIX)

this happened in 1.7.2: https://gfycat.com/OldfashionedZestyFly

As I said it was never a good idea to use short pulses to power a melon farm and I don't think this is even a bug. The melon item is created in the center of the broken block and the retracting piston arm catches it, before it has time to fly to the side. This is excactly what I would expect in a real life situation, where something magically appears out of nowhere and something else in front is moved back.

This is why everybody used sticky pistons with a block in front to break melon blocks. The item would glitch around in the solid block and fly to the front 95% of the time. Here's a simple 16w40 farm, using the observer block: https://gfycat.com/QuarterlySilverHackee

Not yet! :'(

The issue here is when you de-power the piston, it instantly teleports to the 'extended' position causing anything that was moved by the 0.5block movement in the first moving tick to be halfway the block and therefor now inside of the head. Since the head is supposed to do damage when it squashes your face, it also has the property to push out items that collide with it. So some items will decide to go all over the place.

The solution for this would be to not instantly put the block+head into place, it actually overlaps with blocks still moving in front of it for half a block for a tick. Instead it would just retract from the position it is in and the block slide in place.

This means:

1. the piston will retract for 1 tick and be ready for extension after that (thus it will be ready 1 tick earlier)

2. the block will slide into position for 1 tick and thus it will be 'solid' 1 tick later.

This obviously changes timings on everything so we're not doing it now, we might test this in a snapshot after 1.11.

Thank you for helping me resolve this problem

Unable to reproduce per the description of the resolved duplicate ticket.