MC-110244Moving 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).
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; // ... } } }
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
Linked Issues
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
Created Issue:
Moving blocks use 0,0,0 as surrounding to calculate their bounding box
When a moving block moves entities it's 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_oxzpkFix
To fully fix this
MC-110094would need fixing, but at least making it depended on the current position would remove the client/server desyncs it causes.TileEntityPiston.javaprivate 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, /*(MC-???) BlockPos.ORIGIN replaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.
Attachments2
When a moving block moves entities it's 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_oxzpkFix
To fully fix this
MC-110094would need fixing, but at least making it depended on the current position would remove the client/server desyncs it causes.TileEntityPiston.javaprivate 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, /*(MC-???) BlockPos.ORIGIN replaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.When a moving block moves entities it's 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_oxzpkFix
To fully fix this
MC-110094would need fixing, but at least making it depended on the current position would remove the client/server desyncs it causes.TileEntityPiston.javaprivate 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, /*(MC-110244) BlockPos.ORIGIN replaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
When a moving block moves entities it
's 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_oxzpkFix
To fully fix this
MC-110094would need fixing, but at least making it depended on the current position would remove the client/server desyncs it causes.TileEntityPiston.javaprivate 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, /*(MC-110244) BlockPos.ORIGIN replaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.
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_oxzpkFix
To fully fix this
MC-110094would need fixing, but at least making it dependedon the current position would remove the client/server desyncs it causes.TileEntityPiston.javaprivate 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, /*(MC-110244) BlockPos.ORIGIN replaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.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_oxzpkFix
To fully fix this
MC-110094would 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.javaprivate 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, /*(MC-110244) BlockPos.ORIGIN replaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.
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)Fix
To fully fix this
MC-110094would 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.javaprivate 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, /*(MC-110244) BlockPos.ORIGIN replaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)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)Fix
To fully fix this
MC-110094would 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).
Turns out there are issue with that. E.g. fence gates won't push at all then. No idea what's going on currentlyTileEntityPiston.javaprivate 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, /*(MC-110244) BlockPos.ORIGIN replaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.
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)
FixTo fully fix this
MC-110094would 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).
Turns out there are issue with that. E.g. fence gates won't push at all then. No idea what's going on currentlyTileEntityPiston.javaprivate 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,/*(MC-110244)BlockPos.ORIGINreplaced with */this.pos, 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.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-110094would 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.javaprivate 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.
Can't reproduce either. Please attach a world with the setup you used.
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-110094would 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.javaprivate 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; // ... } } }
MC-108673orMC-110094, but closely related to both of them. It's likely that a fix forMC-110094will also make this issue disappear.
16w50a:
Not fixed:
- Cobblestone Walls
This bug is not fixed in 16w50a.
Only with cobblestone walls though
Cannot reproduce with fences or cobblestone walls in 16w50a.
I can reproduce it using the same setup in the screenshot above as long as there are blocks around 0 0 and using cobblestone walls,
Confirm with cobblestone walls. Please reopen the ticket.
Wish the pile of hacks could stop, fixed walls.