Moving blocks use 0,0,0 as surrounding to calculate their bounding box

When a moving block moves entities its bounding boxes are chosen as if it was placed at 0,0,0.
If 0,0,0 is not loaded for the client that also can lead to client/server desyncs as it will see air, opposed to the server which loads it when it does the check.

Way to reproduce:

The armour stand gets moved up even though it is not inside the collision box of the fence.

Video: https://youtu.be/4GFR9_oxzpk
Note: there should be solid blocks around 0 0 0 (so a fence at 0 0 0 could connect to them)

Cause

To fully fix this MC-110094 would need fixing, but at least making it dependent on the current position would remove the client/server desyncs it causes (and it would be a less random source for the actual state at least).

TileEntityPiston.java

private void moveCollidedEntities(float p_184322_1_) {
      EnumFacing enumfacing = this.extending?this.pistonFacing:this.pistonFacing.getOpposite();
      double d0 = (double)(p_184322_1_ - this.progress);
      List<AxisAlignedBB> list = Lists.<AxisAlignedBB>newArrayList();
      this.func_190606_j().addCollisionBoxToList(this.world, BlockPos.ORIGIN /*Cause of MC-110244*/, new AxisAlignedBB(BlockPos.ORIGIN), list, (Entity)null);
      if(!((List)list).isEmpty()) {
         AxisAlignedBB axisalignedbb = this.func_190607_a(new AxisAlignedBB(BlockPos.ORIGIN).setMaxY(1.5)); // Added ".setMaxY(1.5)" to support 1.5 high blocks. (MC-108673)
         List<Entity> list1 = this.world.getEntitiesWithinAABBExcludingEntity((Entity)null, this.func_190610_a(axisalignedbb, enumfacing, d0).union(axisalignedbb));
         if(!list1.isEmpty()) {
            boolean flag = this.pistonState.getBlock() == Blocks.SLIME_BLOCK;
            // ...
         }
      }
   }

:info: This is not MC-108673 or MC-110094, but closely related to both of them. It's likely that a fix for MC-110094 will also make this issue disappear.

16w50a:

Not fixed:

• Cobblestone Walls