Pistons warp entities too much (Pistons pull entities in/through blocks)
Since the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.
Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.12.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.png
This behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it 
Making pistons work perfectly is a bit trickier than I though. I had a fix here, but it wouldn't have worked well in some cases either. So for now here is a list of points that might help:
- block 36 should use the list of collision boxes the block it holds has (currently it's just the rendering hitbox, I believe)
- to the outside block 36 probably should give of the hixbox it would have after finishing the current step, otherwise block-air-block can cause an entity that stands in the air block to get stuck on one of the block 36 and therefore getting inside the other block
- block 36 should only move entities in front of it, not all intersecting
- cauldrons should be able to keep a mob inside while moving (this is a good test if the code is working in the most difficult cases)
Hopefully I will get to update this to more useful info soon.
Linked Issues
is duplicated by36
MC-89370Pistons instantly teleport and visually/physically glitchDuplicateMC-89530Piston to teleportDuplicateMC-89753Cave Spiders get stuck in crusher blockDuplicateMC-89762Sticky piston pulls mob into itselfDuplicateMC-89777Slime block player launchers are finickyDuplicateMC-89992Pulling boats through blocks with pistonsDuplicateMC-91370Retracting rails retract entities other than Minecarts standing uponDuplicateMC-91392Entities messed up when inside cauldron as it is pushedDuplicateMC-91460Piston draws tall Entities upwards.DuplicateMC-92287normal piston push end crystal incorrectlyDuplicateMC-93079Entities are moved when standing on retracting pistonsDuplicateMC-93346Zombies pulled into block after piston pushes themDuplicateMC-93453Mobs Glitching Through WallsDuplicateMC-934800-Tick Sticky-Piston, Armorstand->Retraction DuplicateMC-93557Retracting pistons can pull entities through themselvesDuplicateMC-93891Piston hitboxesDuplicateMC-94432Entities don't collide with retracting pistonsDuplicateMC-97398falling sands glitches trough pistonsDuplicateMC-97442Mobs get sucked back thru pistons if entire body is encasedDuplicateMC-97443Minecarts on a rail that is pushed by a piston get pushed 1 block further than railDuplicateMC-97797Pistons bump the player from the wrong sideDuplicateMC-99144Pistons stuck´s mobs DuplicateMC-99486Pistons Pull Players When RetractingDuplicateMC-99681Pistons become insubstantial when retractingDuplicateMC-99804Through the Nether-ceilingDuplicateMC-100534Piston Suck up entities (when retracting) 1.9DuplicateMC-101504Sticky pistons move all entities within their connected block back with them when they retractDuplicateMC-101904Armor Stand bump into oak fence and teleport back the pistonDuplicateMC-103410Sticky piston adjacent blocks bugging mobsDuplicateMC-103423entities stick to piston extension blocksDuplicateMC-104875Non sticky piston pulls mine cart above itDuplicateMC-106432Piston-Entity BugDuplicateMC-106623Upwards teleportDuplicateMC-106988Piston moves mobs?DuplicateMC-107133Slime blocks on active pistons pull players from below to the top of the slime block.DuplicateMC-108612Piston Translocation BrokenDuplicaterelates to4
MC-101459Living Entities able to step up automatically while fallingConfirmedMC-89043Slime blocks moved by pistons often fail to bounce up the playerFixedMC-108427Pistons Translocation glitchCannot ReproduceMC-109399Entities inside the base of an extended piston get moved in front of it on retractionFixed
- Fixed
![[Mojang] Panda](../../../data/avatars/users/41658.png)
[Mojang] Panda![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png)
[Mojang] Grum (Erik Broes)- 108
- 66
- Confirmed
15w38b - 16w39c
15w38b 15w39b 15w39c 15w40a 15w41b 15w42a 15w43c 15w44a 15w44b 15w45a 15w46a 15w47a 15w47b 15w47c 15w49a 15w49b 15w50a 15w51b 16w06a 1.9-pre1 1.9-pre2 1.9-pre3 1.9-pre4 1.9 1.9.1-pre1 1.9.1-pre2 1.9.1-pre3 1.9.1 1.9.2 16w14a 16w15a 16w15b 1.9.3-pre1 1.9.3-pre2 1.9.3-pre3 1.9.3 1.9.4 16w20a 16w21a 16w21b 1.10-pre1 1.10-pre2 1.10 1.10.2 16w32a 16w32b 16w33a 16w35a 16w36a 16w38a 16w39a 16w39b 16w39c- 16w40a
Created Issue:
Pistons warp entities too much
Since the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.19.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Fix
This fix is just theoretical, I didn't test it. But it probably helps getting the idea what I mean.So the entity should only get moved when this method returns true.
TileEntityPiston.javapublic static boolean shouldPushEntity(EnumFacing pushDirection, AxisAlignedBB block36AABB, AxisAlignedBB entityAABB) { switch (pushDirection) { case UP: return entityAABB.minY > block36AABB.minY; case DOWN: return entityAABB.maxY < block36AABB.maxY; case NORTH: return entityAABB.minZ > block36AABB.minZ; case SOUTH: return entityAABB.maxZ < block36AABB.maxZ; case EAST: return entityAABB.minX > block36AABB.minX; case WEST: return entityAABB.maxX < block36AABB.maxX; } return false; }A nicer and more generic way to implemt it, would be to add a method to AxisAlignedBB.java instead (if there is nothing like that yet), like this:
AxisAlignedBB.java/** * Returns if this AABB is further into direction facing than the other AABB. * * @param other AABB to compare with * @param facing Facing of comparison * @return true if this AABB is reaching further into direction facing * false otherwise */ public boolean isFurtherThan(AxisAlignedBB other, EnumFacing facing) { switch (facing) { case UP: return this.maxY > other.maxY; case DOWN: return this.minY < other.minY; case NORTH: return this.maxZ > other.maxZ; case SOUTH: return this.minZ < other.minZ; case EAST: return this.maxX > other.maxX; case WEST: return this.minX < other.minX; } return false; }And then only moved the entity if block36AABB.isFurther(entityAABB, pushDirection.opposite()) returns true.
Pfff.. This post got way to long for such a simple bug :-P
Thanks for reading
Attachments3
Since the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.19.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Fix
This fix is just theoretical, I didn't test it. But it probably helps getting the idea what I mean.So the entity should only get moved when this method returns true.
TileEntityPiston.javapublic static boolean shouldPushEntity(EnumFacing pushDirection, AxisAlignedBB block36AABB, AxisAlignedBB entityAABB) { switch (pushDirection) { case UP: return entityAABB.minY > block36AABB.minY; case DOWN: return entityAABB.maxY < block36AABB.maxY; case NORTH: return entityAABB.minZ > block36AABB.minZ; case SOUTH: return entityAABB.maxZ < block36AABB.maxZ; case EAST: return entityAABB.minX > block36AABB.minX; case WEST: return entityAABB.maxX < block36AABB.maxX; } return false; }A nicer and more generic way to implement it, would be to add a method to AxisAlignedBB.java instead (if there is nothing like that yet), like this:
AxisAlignedBB.java/** * Returns if this AABB is further into direction facing than the other AABB. * * @param other AABB to compare with * @param facing Facing of comparison * @return true if this AABB is reaching further into direction facing * false otherwise */ public boolean isFurtherThan(AxisAlignedBB other, EnumFacing facing) { switch (facing) { case UP: return this.maxY > other.maxY; case DOWN: return this.minY < other.minY; case NORTH: return this.maxZ > other.maxZ; case SOUTH: return this.minZ < other.minZ; case EAST: return this.maxX > other.maxX; case WEST: return this.minX < other.minX; } return false; }And then only moved the entity if block36AABB.isFurther(entityAABB, pushDirection.opposite()) returns true.
Pfff.. This post got way to long for such a simple bug :-P
Thanks for reading
Since the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.19.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Fix
This fix is just theoretical, I didn't test it. But it probably helps getting the idea what I mean.So the entity should only get moved when this method returns true.
TileEntityPiston.javapublic static boolean shouldPushEntity(EnumFacing pushDirection, AxisAlignedBB block36AABB, AxisAlignedBB entityAABB) { switch (pushDirection) { case UP: return entityAABB.minY > block36AABB.minY; case DOWN: return entityAABB.maxY < block36AABB.maxY; case NORTH: return entityAABB.minZ > block36AABB.minZ; case SOUTH: return entityAABB.maxZ < block36AABB.maxZ; case EAST: return entityAABB.minX > block36AABB.minX; case WEST: return entityAABB.maxX < block36AABB.maxX; } return false; }A nicer and more generic way to implement it, would be to add a method to AxisAlignedBB.java instead (if there is nothing like that yet), like this:
AxisAlignedBB.java/** * Returns if this AABB is further into direction facing than the other AABB. * * @param other AABB to compare with * @param facing Facing of comparison * @return true if this AABB is reaching further into direction facing * false otherwise */ public boolean isFurtherThan(AxisAlignedBB other, EnumFacing facing) { switch (facing) { case UP: return this.maxY > other.maxY; case DOWN: return this.minY < other.minY; case NORTH: return this.maxZ > other.maxZ; case SOUTH: return this.minZ < other.minZ; case EAST: return this.maxX > other.maxX; case WEST: return this.minX < other.minX; } return false; }And then only moved the entity if block36AABB.isFurther(entityAABB, pushDirection.opposite()) returns true.
Pfff.. This post got way to long for such a simple bug :-P
Thanks for readingSince the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.12.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Fix
This fix is just theoretical, I didn't test it. But it probably helps getting the idea what I mean.So the entity should only get moved when this method returns true.
TileEntityPiston.javapublic static boolean shouldPushEntity(EnumFacing pushDirection, AxisAlignedBB block36AABB, AxisAlignedBB entityAABB) { switch (pushDirection) { case UP: return entityAABB.minY > block36AABB.minY; case DOWN: return entityAABB.maxY < block36AABB.maxY; case NORTH: return entityAABB.minZ > block36AABB.minZ; case SOUTH: return entityAABB.maxZ < block36AABB.maxZ; case EAST: return entityAABB.minX > block36AABB.minX; case WEST: return entityAABB.maxX < block36AABB.maxX; } return false; }A nicer and more generic way to implement it, would be to add a method to AxisAlignedBB.java instead (if there is nothing like that yet), like this:
AxisAlignedBB.java/** * Returns if this AABB is further into direction facing than the other AABB. * * @param other AABB to compare with * @param facing Facing of comparison * @return true if this AABB is reaching further into direction facing * false otherwise */ public boolean isFurtherThan(AxisAlignedBB other, EnumFacing facing) { switch (facing) { case UP: return this.maxY > other.maxY; case DOWN: return this.minY < other.minY; case NORTH: return this.maxZ > other.maxZ; case SOUTH: return this.minZ < other.minZ; case EAST: return this.maxX > other.maxX; case WEST: return this.minX < other.minX; } return false; }And then only moved the entity if block36AABB.isFurther(entityAABB, pushDirection.opposite()) returns true.
Pfff.. This post got way to long for such a simple bug :-P
Thanks for reading
Since the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.12.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Fix
This fix is just theoretical, I didn't test it. But it probably helps getting the idea what I mean.So the entity should only get moved when this method returns true.
TileEntityPiston.javapublic static boolean shouldPushEntity(EnumFacing pushDirection, AxisAlignedBB block36AABB, AxisAlignedBB entityAABB) { switch (pushDirection) { case UP: return entityAABB.minY > block36AABB.minY; case DOWN: return entityAABB.maxY < block36AABB.maxY; case NORTH: return entityAABB.minZ > block36AABB.minZ; case SOUTH: return entityAABB.maxZ < block36AABB.maxZ; case EAST: return entityAABB.minX > block36AABB.minX; case WEST: return entityAABB.maxX < block36AABB.maxX; } return false; }A nicer and more generic way to implement it, would be to add a method to AxisAlignedBB.java instead (if there is nothing like that yet), like this:
AxisAlignedBB.java/** * Returns if this AABB is further into direction facing than the other AABB. * * @param other AABB to compare with * @param facing Facing of comparison * @return true if this AABB is reaching further into direction facing * false otherwise */ public boolean isFurtherThan(AxisAlignedBB other, EnumFacing facing) { switch (facing) { case UP: return this.maxY > other.maxY; case DOWN: return this.minY < other.minY; case NORTH: return this.maxZ > other.maxZ; case SOUTH: return this.minZ < other.minZ; case EAST: return this.maxX > other.maxX; case WEST: return this.minX < other.minX; } return false; }And then only moved the entity if block36AABB.isFurther(entityAABB, pushDirection.opposite()) returns true.
Pfff.. This post got way to long for such a simple bug :-P
Thanks for readingSince the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.12.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Fix
This fix is just theoretical, I didn't test it. But it probably helps getting the idea what I mean.So the entity should only get moved when this method returns true.
TileEntityPiston.javapublic static boolean shouldPushEntity(EnumFacing pushDirection, AxisAlignedBB block36AABB, AxisAlignedBB entityAABB) { switch (pushDirection) { case UP: return entityAABB.minY > block36AABB.minY; case DOWN: return entityAABB.maxY < block36AABB.maxY; case NORTH: return entityAABB.minZ > block36AABB.minZ; case SOUTH: return entityAABB.maxZ < block36AABB.maxZ; case EAST: return entityAABB.minX > block36AABB.minX; case WEST: return entityAABB.maxX < block36AABB.maxX; } return false; }A nicer and more generic way to implement it, would be to add a method to AxisAlignedBB.java instead (if there is nothing like that yet), like this:
AxisAlignedBB.java/** * Returns if this AABB is further into direction facing than the other AABB. * * @param other AABB to compare with * @param facing Facing of comparison * @return true if this AABB is reaching further into direction facing * false otherwise */ public boolean isFurtherThan(AxisAlignedBB other, EnumFacing facing) { switch (facing) { case UP: return this.maxY > other.maxY; case DOWN: return this.minY < other.minY; case NORTH: return this.maxZ > other.maxZ; case SOUTH: return this.minZ < other.minZ; case EAST: return this.maxX > other.maxX; case WEST: return this.minX < other.minX; } return false; }And then only moved the entity if
block36AABB.isFurther(entityAABB, pushDirection.opposite())returns true.
Pfff.. This post got way to long for such a simple bug :-P
Thanks for reading
relates to
Since the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.12.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Fix
This fix is just theoretical, I didn't test it. But it probably helps getting the idea what I mean.
@edit: I noticed that there are some moveable blocks that have more than one collision box (e.g. stairs, cauldrons). So the following would probably need to be done for each of them.So the entity should only get moved when this method returns true.
TileEntityPiston.javapublic static boolean shouldPushEntity(EnumFacing pushDirection, AxisAlignedBB block36AABB, AxisAlignedBB entityAABB) { switch (pushDirection) { case UP: return entityAABB.minY > block36AABB.minY; case DOWN: return entityAABB.maxY < block36AABB.maxY; case NORTH: return entityAABB.minZ > block36AABB.minZ; case SOUTH: return entityAABB.maxZ < block36AABB.maxZ; case EAST: return entityAABB.minX > block36AABB.minX; case WEST: return entityAABB.maxX < block36AABB.maxX; } return false; }A nicer and more generic way to implement it, would be to add a method to AxisAlignedBB.java instead (if there is nothing like that yet), like this:
AxisAlignedBB.java/** * Returns if this AABB is further into direction facing than the other AABB. * * @param other AABB to compare with * @param facing Facing of comparison * @return true if this AABB is reaching further into direction facing * false otherwise */ public boolean isFurtherThan(AxisAlignedBB other, EnumFacing facing) { switch (facing) { case UP: return this.maxY > other.maxY; case DOWN: return this.minY < other.minY; case NORTH: return this.maxZ > other.maxZ; case SOUTH: return this.minZ < other.minZ; case EAST: return this.maxX > other.maxX; case WEST: return this.minX < other.minX; } return false; }And then only moved the entity if
block36AABB.isFurther(entityAABB, pushDirection.opposite())returns true.
Pfff.. This post got way to long for such a simple bug :-P
Thanks for reading
Since the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.12.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Fix
This fix is just theoretical, I didn't test it. But it probably helps getting the idea what I mean.
@edit: I noticed that there are some moveable blocks that have more than one collision box (e.g. stairs, cauldrons). So the following would probably need to be done for each of them.So the entity should only get moved when this method returns true.
TileEntityPiston.javapublic static boolean shouldPushEntity(EnumFacing pushDirection, AxisAlignedBB block36AABB, AxisAlignedBB entityAABB) { switch (pushDirection) { case UP: return entityAABB.minY > block36AABB.minY; case DOWN: return entityAABB.maxY < block36AABB.maxY; case NORTH: return entityAABB.minZ > block36AABB.minZ; case SOUTH: return entityAABB.maxZ < block36AABB.maxZ; case EAST: return entityAABB.minX > block36AABB.minX; case WEST: return entityAABB.maxX < block36AABB.maxX; } return false; }A nicer and more generic way to implement it, would be to add a method to AxisAlignedBB.java instead (if there is nothing like that yet), like this:
AxisAlignedBB.java/** * Returns if this AABB is further into direction facing than the other AABB. * * @param other AABB to compare with * @param facing Facing of comparison * @return true if this AABB is reaching further into direction facing * false otherwise */ public boolean isFurtherThan(AxisAlignedBB other, EnumFacing facing) { switch (facing) { case UP: return this.maxY > other.maxY; case DOWN: return this.minY < other.minY; case NORTH: return this.maxZ > other.maxZ; case SOUTH: return this.minZ < other.minZ; case EAST: return this.maxX > other.maxX; case WEST: return this.minX < other.minX; } return false; }And then only moved the entity if
block36AABB.isFurther(entityAABB, pushDirection.opposite())returns true.
Pfff.. This post got way to long for such a simple bug :-P
Thanks for readingSince the recent changes to block 36, entities that get pushed get set right in front of the block 36 collision box.
That makes sense, but it should only happen for entities which collision box is (almost) fully in front of the block 36.
Otherwise entities that just barely reach inside the block 36 from behind get warped in front of it.Steps to reproduce:
1. Build up 2015-09-18_23.35.57.png
2. Remove the redstone block 2015-09-18_23.36.12.png
3. Place the redstone block
4. The armour stand got warped on top of the half slab 2015-09-18_23.36.19.pngThis behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it
Making pistons work perfectly is a bit trickier than I though. I had a fix here, but it wouldn't have worked well in some cases either. So for now here is a list of points that might help:
- block 36 should use the list of collision boxes the block it holds has (currently it's just the rendering hitbox, I believe)
- to the outside block 36 probably should give of the hixbox it would have after finishing the current step, otherwise block-air-block can cause an entity that stands in the air block to get stuck on one of the block 36 and therefore getting inside the other block
- block 36 should only move entities in front of it, not all intersecting
- cauldrons should be able to keep a mob inside while moving (this is a good test if the code is working in the most difficult cases)
Hopefully I will get to update this to more useful info soon.
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
relates to
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
Pistons warp entities too much (Pistons should push entities, not pull them)
Pistons warp entities too much (Pistonsshould push entities, not pull them)Pistons warp entities too much (Pistons pull entities in/trough blocks)
Pistons warp entities too much (Pistons pull entities in/through blocks)
is duplicated by
is duplicated by
2016-04-30_17.06.40.png
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
is duplicated by
is duplicated by
is duplicated by
is duplicated by
[Mojang] Grum (Erik Broes)is duplicated by
relates to
relates to
is duplicated by
relates to
is duplicated by
relates to
So just because it doesn't make sense (Minecraft in general doesn't make sense), you fixed one of the most useful "features" ever. It made so many more things possible and everything it broke could be adjusted for it.
Instead of letting us have incredibly fast transportation, you'd rather make players AFK in minecarts for 10 minutes.
Instead of keeping in easy to make elevators, you leave us with slower slime block elevators or manual elevators.
By getting rid of translocation, you're not going to fix clever mob farm designs. They'll just become laggier.
And besides, this ticket talks about mobs in front of or on the side of block 36 getting pulled through, which is even in my opinion weird. By keeping translocation for mobs which are inside of block 36 (in the piston arm), you'd fix crushers and practically everything else translocation broke while still leaving in useful gadgets like elevators. Or even better, make a separate translocation piston block.
Quasi-connectivity turned out useful and you kept it. Translocation is arguably even more useful, especially now that observers are in the game.
If the Minecraft community ever dies, the game will die along with it. In this case, it wouldn't be hard to give us the best of both worlds, just like Jeb did with fixing hopper item duplication (hopper timers are really consistent in the newest snapshot).
Dupe of MC-89030
Dupe of MC-89030
Dupe of MC-89030
Dupe of MC-89030
Sounds like MC-89030.
Yes, I see the desync now. Only happens in the end dimension as you can move ender crystals in the overworld. If you're so inclined, you can still move ender crystals in the end dimension using MC-89030, I just found out. Reopening.
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
Smells like MC-89030.
This issue duplicates MC-89030
Confirmed for
- 15w50a Currently mainly caused by
MC-89030
caused by MC-89030, resolving as duplicate
user-f2760 MC-89030 moves entities out of blocks, not into them.
When retracting they do, see sethbling's video about it, this issue has been fixed, what you see is MC-89030
when MC-89030 is fixed, and this is still an issue, then this will be reopened, not sooner as it's very likely the same issue as you experience
The environment is supposed to only contain pc details
Duplicate of MC-89030, if you have not, please use the search function in the future
Mobs are able to step up automatically while falling
in 1.8 when pushed by slime blocks (sideways) a entity is able to jump up over a one block gap and up by its automatic step up height
in 1.9 this has been increased to two blocks (shown in v=1VaMGOYdSX8&feature=youtu.be )
For most living entities (inc the player) this can jump up by half a block onto a half slab above,
however for Enderman and Horses this is increased to a whole block (again shown in v=1VaMGOYdSX8&feature=youtu.be )
Summary Table
The following table show how far vertically and horizontaly when pushed by slime blocks (sideways) a mob can move, Horizonally is measured as the air gap inbetween the blocks the entity move from and the block the entity moves to, and vertically is the number of blocks the entity can move upwards above the block the entity was pushed from, NOTE: none of the mobs where jumping at the time of testing (especially the player))
| Mob | 1.8 Horizontal | 1.8 Vertical | 1.9+ Horizontal | 1.9+ Vertical |
|---|---|---|---|---|
| Player | 1 | 0.5 | 2 | 0.5 |
| Villager | 1 | 0.5 | 2 | 0.5 |
| Zombie | 1 | 0.5 | 2 | 0.5 |
| Skelly | 1 | 0.5 | 2 | 0.5 |
| Blaze | 1 | 0.5 | 2 | 0.5 |
| Zombie Pigman | 1 | 0.5 | 2 | 0.5 |
| Horse | 2 | 1 | 3 | 1 |
| Enderman | 1 | 1 | 2 | 1 |
The way to fix this bug would be to disable the automatic step up code whist the entity is falling / not on the ground (like when flying in creative mode)
I'm sorry if this report don't make much sence it's a little hard to explain though 
EDIT
This bug is not a Duplicate of MC-89030 as it can be shown in ' https://youtu.be/Wb0GfHunrRA ' to also affect 1.8.9 which is unaffected by MC-89030
EDIT 2
Added an world where you can automatally test if the bug still affect that version (called 'Bug test World.zip')
EDIT 3
Changed the bug report from only effecting enderman to affecting all living mobs, would like to thank panda for his help suggesting horses as another mob affected by the bug)
Part of MC-89030, "pistons warp entities too much".
[Mod] FVbico, MC-89030 only explains part of this not all, of it as there are 2 things which are going on here:
1: the mobs being pushed to far (Explained by MC-89030)
2: Mobs being pushed up a block (Not explained by MC-89030 as 1. the only nearby pistons are sideways facing and 2. the bug also occurs when you lengthen the slime blocks (make the slime blocks 11 long not 2 long) on so no pistons being nearby (badly explained, but this was used in a enderman farm spawn floors so imagine using it there.)
EDIT: Added screenshot
EDIT 2: Changed mc-89030 to MC-89030 so it links to MC-89030 properly
It may not cover all of this report, but it's nevertheless the same issue.
When MC-89030 is fixed, and this issue still occures, then this ticket will be reopened, no need to update affected versions until then.
Duplicate of MC-89030 – If you have not, please use the search function in the future, to see if your bug has already been submitted.
Panda (reporter of MC-89030) said this issues is NOT a dupe of his bug (MC-89030) and surrested using the /entitydata command to test it so in did and this bug occurred again however often using commands can break things (like external tools can) so to prove this is not a dupe I tried to recreate this bug in 1.8.9 BEFORE MC-89030 was introduced proving these are 2 separate issues see 'https://youtu.be/Wb0GfHunrRA' for proof in 1.8.9 and 1.10 snapshot 15w21b
EDIT: Spelling and clarified about commands breaking things
EDIT 2: Changed mc-89030 to MC-89030 so it links to MC-89030 properly
I actually see my sheep get pushed out of there fences by other mobs and I'll notice after a while a stray pig or cow mixed in with my other mobs. I just thought it was spawning there but now that I saw my sheep actually get pushed through the fence now i am not so sure. I am in 1.10.2. I actually started to think that this and MC-89030 are related. Since the problem might be the Mobs instead of the blocks. Any thoughts? I have to make double fences which seems to help. This might be the result of "fixing" the suffocation issue where mobs get stuck inside blocks. The mobs going through the block is to prevent them from getting stuck Inside it, Hopefully there will be a way to prevent the Mob from going that close to a block in the first place. Maybe if that is possible that could solve this issue?
This is not related to MC-89030, that one also warps players and this one also happens without pistons.
Dupe of MC-89030
Dupe of MC-89030
This is intended. The piston translocation behaviour was a bug that has now been fixed (see MC-89030).
Confirmed for 15w38b
Confirmed for 15w39b
Confirmed for 15w39c
Confirmed for 15w40a
Les3awe: 15w40b is out.
Confirmed for 15w41b
I like this behaviour. It's very useful for a lot of technical applications. Sure it doesn't make sense from a real world perspective, but being able to push a block into an entity also doesn't make sense in the first place. I don't see a downside to it.
Confirmed for 15w42a
Confirmed for 15w43a
Affects 15w43c
[Mojang] Panda: Just to be sure,
MC-91370is a duplicate of this ticket, right?Confirmed for 15w44a, pistons still teleport entities.
MC-89370is a duplicate right?Confirmed for 15w44b
I know Patrick Zimmermann posted a while ago, but note that the costs of this bug outweigh the benefits: most crusher-design XP farms now let the mobs escape by forcing them out of their kill chamber due to this bug when the pistons retract.
1- height mob farms, like rabbit farms, are completely broken because of this bug.
With shifting pistons? Not this bug; also just use soul sand.
Yes it is this bug. Soul sand doesn't do shit, still warps mobs and kill them instead of leaving them were they are supposed to be.
OK, til
Confirmed for 15w45a
bob: Only farms for small mobs are influenced. You can prevent the 2-high mobs from being pulled simply by placing a stationary block in their way.
Victor Uwe Vanderlinde: I guess you want to use splash potion / looting. You can use fall damage to bring the rabbits down to 1 heart: http://s9.postimg.org/u0snjmn0f/2015_11_19_02_09_01.png
An entity is also moved when it stands on the piston block (not the head). See
MC-93079.I added an attachment to show it pulling spiders into itself. You can remove if it is not helpful.
"This behaviour is kind of cool for the technical community, but it doesn't look intended, so better fix it fast before we get used to it"
Well, Etho just made a video today showing this and saying he hoped it was a feature, so look out, world
Sigh. It's a cool trick sure but absolutely terrible in actual redstone.
Well, I hope Mojang finds something between fixing the bug and keeping the feature.
For those who want to watch Etho's video: https://youtu.be/jcxSkOwUhy8?t=7m27s
I also hope it gets kept in some way, this is cool functionality.
I don't; it ruins many crusher designs.
Only because a well-known and loved Minecraft YouTuber likes a "feature" a bug poses, does not mean that all of a sudden it's good to be kept.
Please differentiate between your own opinion and those of who you adore.
Mr. Broes' (Grum) stance towards bugs was very clear: Bugs need to be fixed, and they will, at some point.
We've all seen how much whining and even hate fixing the item elevators caused, so please don't make this the same here, if the tech community gets used to this "feature" at some point.
I second that. It breaks more stuff than it fixes.
Mr. Broes' (Grum) stance towards bugs was very clear: Bugs need to be fixed, and they will, at some point.
I agree, but somebody has to decide first, if it's a bug.
I'd like to see this as intended behaviour. Being able to push a block into a mob makes even less sense. But nobody would call it a bug. Apples growing on oak trees - working as intended. cobblestone can be made out of nothing - working as intended etc.
game play before realism. In the last year we did get very few new things to be creative with. If every new unintentional behaviour, that is different from the way it used to be, is condemned as a bug, this game will be only half as interesting.
This feature adds so many new fun possibilities, and there's almost no real downside. The only complaint I've heard so far is that mob crushers are broken. Folks just be creative! If the spiders are pulled along with the block, let them drop down into a seperate hole, after they're pulled - problem fixed. It even makes sense that a mob that is stuck in a block gets pulled with it, doesn't it? Being creative is what it's all about. Destroying this wonderful feature would be the wrong decision.
ilmango, https://www.reddit.com/r/minecraftsuggestions/
Also, confirmed for 15w50a
ilmango As you know, Panda (the bugpost opener) is THE incarnation of exploiting bugs as "features", a nightmare come true for Minecraft developers.
And if a Minecraft Survival game mechanics expert like him who loves a buggy game (so he can exploit it) decides to see it as bug, as more harmful than useful, then I trust his evaluation.
It's futile to list all the bad and good this bug would mean if the stance of the developers is to fix all bugs at some point, and I don't ever want to have to face a rage even from big YouTubers I respect (the recent bugfix that led to a fix for test137E29's item elevator) that put pressure and caused despicable remarks towards the developers again.
And even more futile if different interests, some of them selfish, collide, which hardly can lead to an agreement of all parties.
For example those YouTubers who like to make videos about such bugs, sell them as "features", the crowd loves it, and as soon as it's fixed before the release version, let's guess who will get the hate?
The YouTuber who made a video in a buggy snapshot version, or the developers who "took away the cool feature"?
It is important to list the positive and negative effects of this bug. This is because the developers clearly don't fix some bugs that are a 'part of the game' e.g. quasiconnectivity unless the bug causes other significant problems. The race condition that allowed the renderer to control hitboxes allowed for item elevators and wireless redstone, but also led to some pretty horrible bugs such as being able to walk through blocks like anvils and chests. When the devs fixed the bug, they weren't fixing item elevators; that was just a side effect. They aren't fixing bugs for the sake of fixing bugs!
What they need to decide is if the benefits if this 'bug' outweigh the costs.
bob "When the devs fixed the bug, they weren't fixing item elevators; that was just a side effect"
I know, I said: "the recent bugfix that >led< to a fix for test137E29's item elevator" - that's exactly what I meant.
I know where you're getting at, why you think it's good to know about the ups and downs of a bug.
What I meant is that it's hard to differentiate for many people WHY someone is for fixing/keeping a bug.
Some people's intent is not the good for the code/tech community, but just their own wallet or showing-off with videos about "cool inventions" by using snapshot bugs which could lead to a bad outcome for the developers in the long run, as I tried to explain.
Snapshots should be treated as such, and many don't, which can cause confusion amongst the viewers.
I don't want to see any reader's opinion being influenced by an opinion that was given under the disguise of having no ulterior motives.
I just hope Panda will very soon have the time to explain the ups and downs, so the devs can make the decision regarding this bug without having to waste too much time to figure out on their own how much it influences the game mechanics
I know Panda is generally not happy with the piston code as it is currently.
Confirmed for 15w51b
Confirmed for 16w05a, but I don't see or want this bug to go away completely. There are quite a few uses (Elevators, etc) for this, but less than the side effects. It would be nice to see a partial fix, while still allowing entity elevators.
Ry M ...the elevators? Are you suggesting the kind of elevator seen in this video of Etho's https://www.youtube.com/watch?v=jcxSkOwUhy8 (LP ep 431)? If so no, we shouldn't keep this. For one this is the exact problem this post is talking about, we either keep the entire bug or remove the bug including the elevator. Sure this elevator is useful and convenient if you're too lazy to use proper mechanics, but the exact same can be said for duplication glitches. We already have perfectly working elevators, just a bit more bulky.
Remember when mobs could fall through the floor in either early 1.8 development versions where if you hit a mob with a block directly below and above it, it would be placed into the ground and if the floor was one thick it would make them fall through, Players included. Sure if it existed today we would be able to "sift" mobs through the floor again in Witch farms and such, but the bug makes gameplay very UNSTABLE.
But really, whats the difference between this and a duplication glitch? You saying you want them to re-add a duplication bug?
Confirmed for 16w06a
Confirmed for 1.9-pre1
Confirmed for 1.9-pre2
Btw I would like to note that in one of Etho's latest LP world videos he used his elevator that used that bug to work and the elevator failed half way through for no apparent reason and randomly worked the next time. Features should work all the time. I'm a bit nervous that this bug isn't going to be patched before 1.9 official, if it makes it that far its going to hurt more when it is removed.
Confirmed for 1.9-pre4
Confirmed 1.9 official...
This bug causes all blaze farms that use pistons to push blaze off ledges to pull blaze back within the piston block.
This bug appears to be caused by the piston momentarily disappearing (see: https://www.youtube.com/watch?v=0b7A4m2SFSQ) and this causes redstone placed on pistons to break (see: https://www.youtube.com/watch?v=7okXYwR4EdU)
Can confirm, they do disappear for a split second, and it would be awesome for Mojang to fix this annoying bug.
Piston crushing mobs causes the mobs to be pulled back along with the piston. I noticed the whole piston acts funny.
It makes the side of the block it is pushing all black when it crushes a mob. I used an armorstand. And it was stuck within the block when I pulled the piston back.
confirmed in 1.9.2
People are beginning to exploit this bug to do some really cool things. See Xisuma's baby cow separator: https://www.youtube.com/watch?v=SR6Qglnc2jY
If Mojang takes their time fixing this, they will break a lot of stuff.
If they don't fix it, they will have a very counterintuitive and user-unfriendly device that pulls (when the real world counterpart pushes) except when it pushes.
Please fix this.
Agreed. The amount of old redstone this breaks is way more than the amount of new redstone this allows. It's unfair to everyone who hasn't exploited this bug.
Unlike the BUD, for example, this bug hasn't been around since the beginning of Pistons.
Plus, the community could always request a block that does this.
To add to the severity of this bug, consider the use of pistons with gravity-enabled blocks on top, like gravel or sand on top of pistons, for example for a door that retracts into the ground. The falling block entity may drop as an item sometimes, or even get pushed through the piston, with the correct setup and timing eventually ending up with piston and gravel/sand replaced, which is not only counter-intuitive, but plainly horrific.
See this video (by xisumavoid, again): https://youtu.be/sFmBQ_115kI?t=5m7s (at minute 5:07, also at minute 6:00)
I think the best course of action we can take is to comment on videos where this bug is used saying something like "Here is why the bug is more harmful than good: [Reasons]" and also provide a link to this page so we can get more votes and bring it higher on the popular reports page. Along with mentioning moving through blocks is just stupid
Protofall I don't believe it is up to discussion whether this is intended behaviour. It is obvious it is not. The only thing that is debatable is the urgency of this bug. However, the sentiment of the technical community is to exploit even very obviously not intended bugs - I doubt it will bring people to not exploiting it.
That it is important to upvote this as much as possible, though, I agree.
This bug will only become more and more harmful with time. It is very useful, and it would be OK if it was closed as "works as intended". It's also counter intuitive, unintended and bad for feature parity with other editions, so it would be OK if it was assigned to someone, just so redstoners know they have to stop using it if they want their systems to work in 1.10. The only bad thing to do with this bug is to keep it in this state, where we don't know for sure whether it's a bug or it became a feature, and it might be fixed after being exploited for years (like
MC-9342orMC-73302), making everyone unhappy.@RimaNari I never said it was intended, I even pin-pointed the exact version this bug appeared (15w38a or somewhere around there, can't remember) and it happened to appear in the version after another piston/entity bug was fixed (Mobs weren't getting moved by retracting pistons...well they fixed it too much I guess). The fact that this bug allows you to move through blocks also confirms this is a bug, but some people out there think that moving through walls is normal, they really do...the internet must be haunted by ghosts or something.
I have no interest in the world for these new elevators and such that exploit this bug, at the end of the day they'll end up like test's item elevator. The only bug I like and want to see stay in some way is the boat/ice bug, however I think they should make a new transport vehicle like a bob-sled for this and fix up the boats.
@Azelef Yes, some kind of view from Mojang on this whether it is all good or needs fixing would be greatly appriciated. But its definately not an intended feature.
This might be more of a problem with how end portals handle entities, but in the video this bug is used to help infinately duplicate entities: https://www.youtube.com/watch?v=N8R4322tcaQ&feature=youtu.be&a . This is getting out of hand : /
Sorry for partially being meta, but that's an irresponsible move of that Youtuber, we don't want people to find it appealing to have this bug being kept in the game, or the Devs will get loads of hate again if such a "feature" is being removed afterwards as a side effect of necessary bug fixing, like back then with test137E29's item elevator.
I don't think it's that irresponsible to make a video about a bug exploit. After all, the reporter of this bug does it all the time.
Although this bug definitely needs to be fixed. It's a highly pernicious bug that breaks a lot of things that ought to work.
I can confirm this bug for 16w15b, most likely 16w14a as well.
"Pistons should push entities, not pull them."
I don't think the new title is correct for two reasons :
-The cause of this bug is the fix of
MC-88101, which is about pistons not moving entities when retracting. If you were inside a piston arm, you would expect to be pulled inside the piston upon retraction (although there is no reason to go through the piston itself). So sometimes, pistons should pull entities.-The bug isn't only about pistons pulling entities, it is also about pistons pushing entities they shouldn't push, and moving them too much (minecarts on rails move two blocks when pushed, entities don't stay inside cauldrons...).
That better?
Through
[Mod] Neko fixed, it sucks when your native language is Dutch. XD
Yes, that title seems good, it describes the bug without restricting it to one particular case.
Ah, no worries
I would love to know whether this is a bug or a feature.
Through blocks doesn't seem like something mojang wants.
When you say through blocks I assume you mean entities being pulled through the piston? If it was to be fixed, would piston translocation elevators/conveyors still work? There are people who have built amazing things with translocation, but a lot of things have also been broken.
Is the bug when a piston pushes a block into an entity and still pulls it, or is it just the unusual pulling /pushing in general?
Look at the images.
@Mikha Davids This bug is the translocator bug that you know and it exists because when Mojang patched another piston bug in the 1.9 snapshots, the piston translocator bug appeared due to the fix.
The whole point of trying to get this bug fixed is to break the piston translocators and make it so you can't move through the piston because moving through walls/blocks makes no sense and is silly and the existence of this bug also breaks a bunch of other stuff.
As for people who have built many things with this, remember the item elevator bug that was fixed in 1.9. Also a bug people liked, but the negatives out weighed the positives just like this.
Thank you Protofall
+1
This is a very important issue to get fixed. It completely breaks a lot of contraptions and farms, so i can't imagine it being an intended feature.
I just realised something, eventually this bug will be patched. I know this because Mojang has a thing of "All versions will be the same one day" hence why MC:PC is now getting that "Auto-jump" feature from MC:PocketEdition. But recently one of the MC:PE devs showed a gif of a sticky piston moving a chest. Thats not the important part though, whats important is that there was a lever mounted on the piston and it didn't pop off like it does in MC:PC (At least putting redstone dust on top of a piston will do this). The reason it pops off in MC:PC is that the piston disappears for a split second and THAT glitch is what allows entities to move through pistons. So either Mojang is going to break MC:PE by making the piston disappear for a bit or they will remove this bug.
@Protofall It's not that simple. First, there are two separate bugs :
-Pistons move entities too much
-Retracting pistons are block 36 and therefore behave like a pushed block.
The redstone dust on top of pistons disappears because dust would disappear if it was on top of a pushed block. Fixing the second problem would only be one half of the issue.
If you look at the source code, you will understand why it happens, and if you try to fix it, you will understand why it isn't fixed : that would require to rewrite a good chunk of the hitbox code (which was itself rewritten in 15w38 to fix a few bugs (wireless redstone, test137 elevators, pistons not pulling entities properly)). The devs don't like rewriting big parts of the code (that's why it took so long to fix the old hitbox bugs and why MC-4and
MC-9553are still open). This will be fixed when someone will decide to spend a week on it.(Second half that didn't submit before)
However on the filp side Docm77 mentions here: https://www.youtube.com/watch?v=mWZabYkI9xA 26:30 that he spoke to a MC:PE developer and he hinted that he likes this bug.
But based off of that I have no idea how you could have levels/redstone dust mounted on a piston (ie. the piston never disappears) and have the translocator bug at the same time. Its one or the other...and if people still really really want a translocator then Mojang should just make a proper feature for it. ie. an entity pipe (Which could also fix item elevators).
http://photos1.blogger.com/blogger/1648/2486/1600/Tube.jpg
(After seeing Azelef's comment)
@Azelef well I haven't seen the source code myself so my words are based off of those who I hear from such as Panda, Sethbling and others. I'll take your word on the 2-bugs thing, but that doesn't completely make sense. Sethbling showed that if there is a sideways facing retracting piston with a block on it (So it can't pull you through) and a minecart or something on the other side and you hold right click in the direction of the cart then you will hop in the minecart and he claimed thats because it dissappears for a second. Maybe this is when the piston turns to id:36 or back, but I can't tell.
If it takes them a few months to fix this bug then I'm I guess thats okay with that, I'd just like to hear Mojang's "official" opinion on it and if they want to eventually remove it or keep it.
Protofall darngeek/Mr. Wustenhoff is only one of the Devs. All Devs seem to talk about features and bugs.
If you look into
MC-108you can read that Mr. Broes initially wanted to fix quasi-connectivity in 2012/2013 as it is a bug, but he got outvoted by Mr. Adams and Mr. Bergensten who declared it a feature back then.We don't have confirmation yet (real confirmation from Devs' side) whether the majority of the Devs see this bug as "feature" now, and I really hope they won't be swayed what big YTers who try to influence the public+Devs' opinion say about it, but rather listen to that part of the tech community who is truly concerned about the game itself and who considers also negative effects of it and is not focussing on just new farms/concepts that creates views/subscribers for their channels.
Yes, you can do neat stuff with warping pistons, but that's exactly why Panda wanted it to be fixed before 1.9 release, so the community will not get used to it and then hate on the Devs when/if a bugfix comes and removes it again. That's what we're generally really worried about and why we're so strongly trying to defend bugfixing of bugs with some really bad effects.
That big YTers like Docm77 declare publicly that they want that bug to stay in - although they should know it causes also some bad things - is irresponsible, as they know fans tend to like what their idols like, which can - with real fanatics - again result in death threats against the Devs, and neither viewers nor fellow YTers should thus imo use it as argument here on Mojira. Of course quoting Devs themself is fine and logical, if the quote is 100% correct and true, and not taken out of any context where it could be misinterpretable or does not mirror the reason of why that statement was being said.
Like you said, it's another thing to ask for a separate feature that would do the same, but it's imo wrong to say a bug with (also) bad effects should stay in. As Mojang seems to plan to have everything, incl. Redstone, being the same across all MC platforms, the Devs probably need to keep that "equalization" in mind as well.
Azelef That change was from my perspective not made to intentionally fix test's item elevator, but mainly to have entities, be it mobs or players, not glitching through/into blocks.
As side effect of that change, yes, test's item elevator wasn't working anymore, but Panda (the bugposter) tried to convince Mojang to keep test's old item elevator as it was a feature for such a long time, and people really loved it. Luckily there are, as you know, alternatives.
@Meri Diana Pretty much my thoughts on it too, +1
@Protofall
The piston disappears because block 36 has a weird hitbox (its hitbox moves with time, so it starts with a 1 block offset). Then in 2 gameticks, the offset is reduced to 0 and the block 36 becomes a normal block again.
@Meri Diana
Yes, they didn't rewrite the code only to fix items elevators.
What they fixed includes :
-Glitching into chests/anvils, hitboxes changing when looking at stuff, wireless redstone
-Shifting floors
-Items bouncing on staircases/in cauldrons
-Pistons not always pushing entities they should push
-Pistons never pulling entities they should pull
-That one elevator design
-All that stuff Panda thinks shouldn't happen.
EDIT: this is a separate issue see MC-101459 for more however a I left this here for the consistency of this bugs comments - sorry for going off-topic
I would add some of the info I posted on my duplicate bug report (MC-101459):
Enderman can jump over a 2 block gap and a block up when pushed by slime blocks or pistons (see screenshots / video) https://www.youtube.com/watch?v=1VaMGOYdSX8&feature=youtu.be
However in 1.8.9 the enderman fell in the 2 block gap which I belive is the intended behaviour, in my test (see screenshots / video) there are 2 things going wrong:
1: the mobs being pushed to far (Explained by This bug)
2: Mobs being pushed up a block (not clearly explained by this bug as 1. the only nearby pistons are sideways facing and 2. the bug also occurs when you lengthen the slime blocks (make the slime blocks 11 long not 2 long) on so no pistons being nearby (badly explained, but this was used in a enderman farm spawn floors so imagine using it there
Danny N The behaviour of the endermen you show is unrelated to this bug post. It happens because endermen have a step height of 1 block (it should be similar with horses).
They don't get warped by pistons in any way in your video, just pushed regularly.
You could also reproduce the behaviour you show by using /entitydata on the endermen to set their motion.
So please open an other report about that to avoid confusion. Thank you
Panda, I did open another bug report (MC-101459) and I got closed as a duplicate, secondly this enderman behaviour didn't occur in 1.8.9 hence something occurred in the dev of 1.9 to cause this. I will test entitydata though to see if it still occurs in 1.8.9 and 1.9.4 and see if that may get MC-101459 reopened - Thanks
Panda just done some testing and have found what I said in MC-101459 to also affect 1.8.9 detailing that you was right and these are 2 separate issues over the same thing - thanks
Confirmed for 16w21b.
Ah, so much anger over one little bug. To add my opinion, I would like the bug declared "Works as Intended" the way quasi-connectivity was. To address Meri's concerns, I am a technical player with no YouTube channel, so I have no reason to promote this bug other than for my own enjoyment. Yes, some contraptions like crushers are broken, but other simple crusher designs have been created, some of which are even enabled by this bug. Converting existing farms from one design to another would, for me, be only a minor inconvenience. I consider the bug useful, but not overpowered the way duplication glitches are. It merely adds an alternative form of transportation, which, in the case of mob elevators, takes more time and resources to build but is faster and more predictable than a simple water stream or minecarts. I wouldn't be heartbroken if it were removed, but I'd like it to stay. Regardless, I think the developers should make the decision soon, so people don't get used to it only for it to be taken away. The concern about resentment toward the developers is very real.
I agree that they should make the decision faster, I already see the same thing coming for
MC-101567which allows you make 1x1 stripmines. But I don't agree that this fully works as intended, since it can apparently also pull entities through other blocks. At least that should be fixed. It wouldn't break elevators.Apart from what people may think about this bug, it is a serious one indeed and therefore needs both clear and soon confirmation as a bug or confirmation as intended/tolerated feature from the developers. It has been seen recently which effect the long-time neglecting of a bug and then the fixing of it has on the community - this should not be repeated.
[~Seamus Callaghan]
So basically you'd like it to be marked as intended, but wouldn't be too annoyed if it was removed. Speaking on quasi-connectivity there are rumours it might be removed (Since pocket edition wouldn't be able to handle it...really stupid and probably shouldn't happen, but that may happen when "All MC platforms are the same")
So regardless of if it should stay or be removed this is infact a bug that was a side affect of a bug fix, just saying incase you didn't know. Is the reason you like this bug the fact that you can move through blocks (Pistons) or is it "This bug makes a really fast and simple-ish elevator/switcher/other_redstone_device so I'd like it to stay"?
The thing about this bug that frustrates me the most isn't really that the bug is bad for the game (In my view), its that most people refuse to call it a bug and for some reason think moving through blocks is okay...I just don't get that.
(Btw how do I properly @ someone? Edit: Ty Meri)
Protofall You hover over their name, it can be different from the login/username, e.g. I get displayed as "Meri Diana", but my username is "LapisDemon".
Then you take their username, e.g. LapisDemon, put it into square brackets and add a Tilde before their name (like so, example with blanks): [ ~ LapisDemon ]
You can find more text editing help here
I very much agree with you btw, it's a bug, no matter if some would like to have it as FEATURE.
Same goes for QC like you already said, but that being said, removing a bug that became (at least temporarily) a feature, doesn't mean in some cases they couldn't consider reintroducing it back as feature again, but then with "clean code".
I don't expect them to port this bug over to PE/the other MC versions generally, and although the WIN10-pistons look very bad currently, compared to Java-pistons, their pistons are still work in progress, I'd very much assume.
Piston warping does not exist in WIN10 MC, and feature parity is a thing Microsoft/Mojang absolutely wants (I also got a statement regarding that by a Microsoft official).
And I also agree and said it already several times that the Devs/Mojang/Microsoft shall state that this is not a desired and intended behaviour with the piston warping, as there are people in the Java-tech community who abuse this bug for their farms/contraptions, and we know what happens if things that seem at least partially useful get removed after a while.
The sooner this gets either fixed or at least declared as a bug officially, the better.
I don't think they will remove QC, because if they really wanted precise feature parity, they would have made the PE/win10 pistons as fast as the PC pistons (they are currently twice as slow, and retraction does not remove the block instantly). Another QC like bug they fixed in PE is
MC-5726, which nobody seems to see as a bug."Piston warping does not exist in WIN10 MC" It does, but it's not the same as PC piston warping. A piston can push you inside an other piston, and if you power this other piston, you can move again. It's buggy and unreliable, but it exists.
"The sooner this gets either fixed or at least declared as a bug officially, the better." I think everyone agrees on this point.
Azelef Maybe at this point we should consider a Redditpost over on Mojira or we might go into meta, or to things not 100% applicable to this bug, but let me state something quick:
They did not "fix a (JAVA-MC) QC like bug in PE", there has never been QC in the first place in PE/WIN10.
I also already said that their pistons are buggy (as hell), they are brand new and a matter of a lot of improvements.
Additions are rarely without any bugs, so you can't tell by their current behaviour how they might end up to be.
The only thing we can do is to give reasonable input.
I've read now from several Mojang/Microsoft-MC Devs that they consider QC annoying, unreliable,
How big is the chance that QC will remain in Java-MCPC, or other things that are obviously bugs like this where you can pull an entity through a piston?
I tried and still try my best to convince them to introduce things that can replace QC, as the BUD block can't from what I saw (although it adds a lot of more neat possibilities), and I hope others will still contribute for a general topic about improving Redstone generally, not only pistons.
"We should consider a Redditpost over on Mojira or we might go into meta" Done. https://reddit.com/4ol3rk .
Protofall Please stop editing your comments repeatedly, the system sends an email to all 72 people watching this bug every time you click save.
As to your last comment, that is not relevant to this or any specific bug and thus needs to move to the Reddit or forums.
fienxjox Oh sorry, I didn't realise editing comments updates people. I couldn't get the [~ "name" ] working before, but it doesn't matter now. Thanks
Protofall, use preview (blue rectangle with white lines) in the future
Confirmed for 1.10.2
It may be fun for the technical community, but I don't like this bug at all. It breaks a lot of stuff and doesn't make sense. I actually don't like any of the bud functionality either. I'd be happier if there was a dedicated bud block instead of making redstone more confusing with all these edge cases. It's just a pain. I don't get why someone would like a clunky broken thing instead of a intuitive polished one. But we see this all the time - gamers playing broken early access titles and enjoying them more than polished ones just because they can break stuff even more. It sucks. Redstone rules should be more consistent. If people want new functionality, there should be new blocks that provide that functionality. Devs, please fix this bug.
Matej Zavernik This is not the place for discussion. Please post your answer here so people can answer and discuss without notifying hundreds of other people that just want to keep an eye on this bug report: https://reddit.com/4ol3rk
(I'd actually really do want to answer something to you based on what you wrote, but first please carry this over to reddit.)
sad day. One of the most useful piston behaviours gets removed after being ignored for a whole year and two versions. It did more good than harm
ilmango All bugs need to be fixed.
Panda and I "preach" it every time that one shall not rely on bugs as they might eventually be fixed.
The Devteam is highly understaffed, so if the bug does not get fixed rightaway, it's foreseeable, even more so with that buggy piston code which one cannot just simply fix quickly.
To use this as argument against them and call it ignorance is inappropriate.
One should rather try to work constructively with them and try to convince them of a replacement for what a bug caused.
If one attacks them it's rather unlikely they would.
It's open for interpretation what should be considered a bug. If I would make a bug report, that piston heads can penetrate entities, it would be marked as "Works as intended". But the behaviour is just as weird as being pulled through a piston or floating half a block over a fence block. All of those weird behaviours are useful for the gameplay.
It is not open for discussion what is considered a bug.
Also Quasi-Connectivity is. Only because a bug can have useful outcomes does not make it lesser a bug.
And if a Dev fixes it, it is definitely considered a bug.
I agree that "quirks" are what makes the game being fun for "crazy" technical people like us, but I insist on rather asking for a "clean" implementation of "quirky" stuff than using real bugs which can change or even completely vanish at ANY time due to implementation or removing of other code.
So if the piston warping would have been removed incidentally by another bugfix which might not even be really related to this one, or "naturally" by an overall clean code after 4 years or more, that would have been better?
You know as well as I do that the longer a bug stays, the more the community sees it as "feature" and will be sad or, worse, aggressive, when that bug gets naturally or incidentally fixed.
I just say "test137E29's item elevator" and the whole QC discussion where Panda and I tried our best to find a compromise with a proper replacement if the QC bug would be removed.
And the longer the community sees something as feature which is but a bug that can (again!) vanish at ANY time, not even intentionally, the more hate the Devs will get, and I'm having enough of seeing remarks such as death threats pointed towards them and will thus always advocate for a bug with "useful outcomes" to be fixed as soon as possible, and rather try to ask for a replacement sometime in the feature (e.g. a second big Redstone Update), and not cling onto old behaviour that was caused by a bug.
You are always free to play the old versions, if you do prefer so.
For any further discussion we should really not use this bugpost here, the mods will already send us to Hell for this.
It was was a bug, it is quite plain to see that stuff shouldn't move through what appear to be solid blocks.
The reason why it happened was rather hard to figure out, the way to fix it even more so. I had tried it several times already but wasn't able to narrow down what was causing it.
Yesterday I was working on some ShulkerBox related boundingbox issues and noticed the code was a copy of parts of the piston code, so I decided to give it another shot.
After some hours of messing around and not getting anywhere again, I remembered we added a system to display extensive debug overlays, added one that was relevant to this issue and very quickly found the reason for the weird teleporting like behavior. Some hacking on the issue later solved it.
I agree, it was in the game far too long but this code is not made by anyone at Mojang, no-one fully understands how it works (though I might be getting close now). This and a general lack of manpower makes some bugs live longer than anyone wants.
Bugs are bugs and they will eventually get removed from the game.
anonymous2342 You didn't understand that, "making sense or not" is not the main issue here, it is that it was a BUG.
All bugs will be removed some day, intentional via bugfixing them, or unintentional, by fixing other bugs or implementing new code which might automatically fix bugs such as this one.
I "love" how guys like you list some accusations first and then are like "but hey pls add a block which does the same, kthxbye".
If you want to have something from someone, package your arguments why it is a loss for the tech community in words which are not accusatory but explanatory.
Wrong. I was one of the people who tried to convince Microsoft/Mojang to give the JAVA-MCPC-community a replacement for Quasi-Connectivity if they'd fix that bug.
YES it is a BUG.
And from how I see how they "tick", it seems rather that they couldn't find a way to give us a proper replacement for QC yet, so they left it in currently.
Whole Redstone system needs a lot of fixing, it works different from PE/WIN10 and will need some time until it is fixed and some sort of "feature parity" will be achieved.
Until then QC might still be in the game, but I would make bets anytime that it'll be fixed one day, one way or another, intentional fix, or automatically when the code is squeaky-clean.
Or maybe everyone will have gone to the PE/WIN10-version then so MS can simply shut down JAVA, who knows?
The Minecraft community will never die, as you overdramatizingly say it. At the very least not PE and anything educational-related.
The Java-tech-community might be more "tamed" or not as "innovative", and thin out/we might become less in number, yes, but let's face it:
We are only a comparably small group which Microsoft does not need to take care of really, no matter how many influencable YTers are out there with their creations.
In order to survive as YTers they will just follow what MS lays as a path and go with it.
So, maybe we Java-techies will die out one day, yes, but do you really think it's a concern for them if we're not their target group after all?
But I don't really think we will "die out", it's just that the contraptions will change. Not as mind-blowing and breathtaking anymore maybe, but still very useful and "clean", surely.
The majority of players are fine with comparably mediocre tech stuff or just want to play a minigame, and, being a business, MS will surely rather please its target audience, which we are surely not, I'd say.
We have to see MS as business company and act accordingly.
So all we can do is to try to make them understand that we are a crazy but lovable bunch who wants to show innovation and make this game more fun.
We have to convince them to give us additions into the game via clean code (not via bugs) that can also be implemented into the other platforms for feature parity.
But we surely cannot get there by making accusations.
We need arguments that are mature and appeal to their business sense.
As much as I understand you and everyone else (and yes, I do, or I wouldn't care as much about QC and everything related to MC Tech etc. and also talk against some Devs' decisions), it is not as you were not being warned since this bug was occurring, that it might vanish one day again.
Please take further discussions to the mojira reddit.
First of all this is NOT a forum!! And if I am reading correctly. You guys are being very ungrateful. Many people have been waiting for this fix along time. I am aware of bugs with redstone and pistons obviously becoming more useful than intended however that is why I don't get used to it unless Mojang says they aren't going to fix it. Btw. When you guys keep commenting here it notifies everybody involved with this. For many it is annoying. Please with all due respect please control yourselves. To Mods and FVbico my deepest apologies for my last comment on this!!
Then why do we have comments in jira at the first place? IT MUST BE DISABLED! Some people cant be controlled!
John Price It's for on topic discussions that don't get out of hand, big/off topic discussions go to the reddit page.
Smaller things, like providing new info about the bug, how it can be fixed, stating it's fixed/affects a new version belong in the comments.
Moving through blocks has been fixed, but few issues originally posted on this report still remain:
Entities get moved by open fence gates.
Entities now effectively don't get moved by cauldrons.
Stairs I'd consider fixed.
Those are different from the main issue tho.
This ticket in general is about pistons moving entities in/through them, not that fence gates/cauldrons give unexpected behaviour when puched with a player by pistons.
That part you're refering to is about how to fix pistons in general.
user-f2760 The description says differently.
Part of a general piston fix suggestion.
Is this the glitch that allows the amazing elevators and transport systems?
No, this is the bug that destroyed some spider farms and item-related piston machines and that's luckily now fixed. You can all stop commenting here.
Guys we still have lots if bugs we can exploit! Pistons, dispensers and droppers getting powered from the block above... but only if they get a block update. Being able to fly by hitting yourself with arrows shot by you. Boats going super fast on ice. Redstone updating in a random order. Go argue about those. This one got fixed already.
This still affects items. Create a new ticket or change this one?
The new ticket for items is apparently
MC-108427.