MC-116877Collision checking during Block placement only uses default state
The bug
When placing blocks, the default state of the block is used to check for collision with entities when deciding if it should be allowed to be placed.
This can lead to some strange valid placement conditions for certain blocks that have different collision boxes depending on state.
Blocks that I've found so far that are affected include Ladders, Fence Gates, Slabs, Anvils, End Rods, and Trapdoors.
Examples
- Placing Ladders on any side of a Block always succeeds unless an Entity is in the southern part of the Block that the Ladder will occupy, which is the location of the collision box of a north-facing Ladder, which is the default state.
- You can place upper Slabs intersecting an Entity's collision box if it is standing on a slab and partially intersecting the top of the Block you want to place the Slab in, assuming that Block doesn't have a bottom Slab already.
Code analysis
Based on 1.11.2 decompiled using MCP 9.37
The method net.minecraft.world.World.mayPlace(Block, BlockPos, boolean, EnumFacing, Entity) calls blockIn.getDefaultState().getCollisionBoundingBox(this, pos) and checks if this box intersects with the collision boxes of any Entities at the BlockPos parameter. Replacing the Block parameter with an IBlockState and using it instead of the default state to get the collision box may fix the problem.
Linked Issues
is duplicated by3
Created Issue:
Collision checking during Block placement only uses default state
When placing Blocks, the default state of the Block is used to check for collision with entities when deciding if it should be allowed to be placed.
This can lead to some strange valid placement conditions for certain blocks that have different collision boxes depending on state.
Blocks that I've found so far that are affected include Ladders, Fence Gates, Slabs, Anvils, End Rods, and Trapdoors.Examples:
- Placing Ladders on any side of a Block always succeeds unless an Entity is in the southern part of the Block that the Ladder will occupy, which is the location of the collision box of a north-facing Ladder, which is the default state.
- You can place upper Slabs intersecting an Entity's collision box if it is standing on a slab and partially intersecting the top of the Block you want to place the Slab in, assuming that Block doesn't have a bottom Slab already.
Code analysis:
Based on 1.11.2 decompiled using MCP 9.37
The methodnet.minecraft.world.World.mayPlace(Block, BlockPos, boolean, EnumFacing, Entity)calls
blockIn.getDefaultState().getCollisionBoundingBox(this, pos)and checks if this box intersects with the collision boxes of any Entities at the
BlockPosparameter. Replacing the Block parameter with an
IBlockStateand using it instead of the default state to get the collision box may fix the problem.
Environment
Windows 7 64 bit
Java 1.8.0_45 64 bit
When placing Blocks, the default state of the Block is used to check for collision with entities when deciding if it should be allowed to be placed.
This can lead to some strange valid placement conditions for certain blocks that have different collision boxes depending on state.
Blocks that I've found so far that are affected include Ladders, Fence Gates, Slabs, Anvils, End Rods, and Trapdoors.Examples:
- Placing Ladders on any side of a Block always succeeds unless an Entity is in the southern part of the Block that the Ladder will occupy, which is the location of the collision box of a north-facing Ladder, which is the default state.
- You can place upper Slabs intersecting an Entity's collision box if it is standing on a slab and partially intersecting the top of the Block you want to place the Slab in, assuming that Block doesn't have a bottom Slab already.
Code analysis:
Based on 1.11.2 decompiled using MCP 9.37
The methodcalls
blockIn.getDefaultState().getCollisionBoundingBox(this, pos)and checks if this box intersects with the collision boxes of any Entities at the
BlockPosparameter. Replacing the Block parameter with an
IBlockStateand using it instead of the default state to get the collision box may fix the problem.
When placing Blocks, the default state of the Block is used to check for collision with entities when deciding if it should be allowed to be placed.
This can lead to some strange valid placement conditions for certain blocks that have different collision boxes depending on state.
Blocks that I've found so far that are affected include Ladders, Fence Gates, Slabs, Anvils, End Rods, and Trapdoors.Examples:
- Placing Ladders on any side of a Block always succeeds unless an Entity is in the southern part of the Block that the Ladder will occupy, which is the location of the collision box of a north-facing Ladder, which is the default state.
- You can place upper Slabs intersecting an Entity's collision box if it is standing on a slab and partially intersecting the top of the Block you want to place the Slab in, assuming that Block doesn't have a bottom Slab already.
Code analysis:
Based on 1.11.2 decompiled using MCP 9.37
The method net.minecraft.world.World.mayPlace(Block, BlockPos, boolean, EnumFacing, Entity) calls blockIn.getDefaultState().getCollisionBoundingBox(this, pos) and checks if this box intersects with the collision boxes of any Entities at the BlockPos parameter. Replacing the Block parameter with an IBlockState and using it instead of the default state to get the collision box may fix the problem.
When placing Blocks, the default state of the Block is used to check for collision with entities when deciding if it should be allowed to be placed.
This can lead to some strange valid placement conditions for certain blocks that have different collision boxes depending on state.
Blocks that I've found so far that are affected include Ladders, Fence Gates, Slabs, Anvils, End Rods, and Trapdoors.Examples:
- Placing Ladders on any side of a Block always succeeds unless an Entity is in the southern part of the Block that the Ladder will occupy, which is the location of the collision box of a north-facing Ladder, which is the default state.
- You can place upper Slabs intersecting an Entity's collision box if it is standing on a slab and partially intersecting the top of the Block you want to place the Slab in, assuming that Block doesn't have a bottom Slab already.
Code analysis:
Based on 1.11.2 decompiled using MCP 9.37
The method net.minecraft.world.World.mayPlace(Block, BlockPos, boolean, EnumFacing, Entity) calls blockIn.getDefaultState().getCollisionBoundingBox(this, pos) and checks if this box intersects with the collision boxes of any Entities at the BlockPos parameter. Replacing the Block parameter with an IBlockState and using it instead of the default state to get the collision box may fix the problem.
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Windows 7 64 bit
Java 1.8.0_45 64 bit
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
When placing
Blocks, the default state of theBlock is used to check for collision with entities when deciding if it should be allowed to be placed.This can lead to some strange valid placement conditions for certain blocks that have different collision boxes depending on state.
Blocks that I've found so far that are affected include Ladders, Fence Gates, Slabs, Anvils, End Rods, and Trapdoors.Examples:
- Placing Ladders on any side of a Block always succeeds unless an Entity is in the southern part of the Block that the Ladder will occupy, which is the location of the collision box of a north-facing Ladder, which is the default state.
- You can place upper Slabs intersecting an Entity's collision box if it is standing on a slab and partially intersecting the top of the Block you want to place the Slab in, assuming that Block doesn't have a bottom Slab already.
Code analysis:
Based on 1.11.2 decompiled using MCP 9.37
The method net.minecraft.world.World.mayPlace(Block, BlockPos, boolean, EnumFacing, Entity) calls blockIn.getDefaultState().getCollisionBoundingBox(this, pos) and checks if this box intersects with the collision boxes of any Entities at the BlockPos parameter. Replacing the Block parameter with an IBlockState and using it instead of the default state to get the collision box may fix the problem.The bug
When placing blocks, the default state of the block is used to check for collision with entities when deciding if it should be allowed to be placed.
This can lead to some strange valid placement conditions for certain blocks that have different collision boxes depending on state.
Blocks that I've found so far that are affected include Ladders, Fence Gates, Slabs, Anvils, End Rods, and Trapdoors.Examples
- Placing Ladders on any side of a Block always succeeds unless an Entity is in the southern part of the Block that the Ladder will occupy, which is the location of the collision box of a north-facing Ladder, which is the default state.
- You can place upper Slabs intersecting an Entity's collision box if it is standing on a slab and partially intersecting the top of the Block you want to place the Slab in, assuming that Block doesn't have a bottom Slab already.
Code analysis
Based on 1.11.2 decompiled using MCP 9.37
The method net.minecraft.world.World.mayPlace(Block, BlockPos, boolean, EnumFacing, Entity) calls blockIn.getDefaultState().getCollisionBoundingBox(this, pos) and checks if this box intersects with the collision boxes of any Entities at the BlockPos parameter. Replacing the Block parameter with an IBlockState and using it instead of the default state to get the collision box may fix the problem.
is duplicated by
relates to
relates to
is duplicated by
![[Mod] SPGoding](../../../data/avatars/users/44622.png){kind=small}
relates to
The Bug:
Relates to MC-116877.
When you have a block with a block state in item form and place it, the entity collision checking ignores the block state. This can lead to some strange valid or invalid placement conditions for certain blocks that have different collision boxes depending on the block state.
Steps to Reproduce:
- Build the configuration as seen in MC-221256.png
. - Give yourself a slab with the "double" BlockStateTag using the following command:
/give @s end_stone_brick_slab{BlockStateTag:{type:"double"}} 1 - Position yourself on the edge of the Enchanting Table.
- Place the slab on the side of the Gray Wool block to the left of the Enchanting Table.
The block is placed even though it collides with the player's hitbox.
Examples from Original Report:
If you use this command:
/give @s chain{BlockStateTag:{axis:"y"}} 1
and aim at the side of a block with the item, the entity collision checking thinks that the chain will be placed horicontally even though you place it vertically. This means that for exmple when you are standing on the edge of a non-full block like an enchanting table you will be able to place the chain inside yourself when aiming at the side of a block.
If you use this command:
/give @s end_stone_brick_slab{BlockStateTag:{type:"double"}} 1
and aim at the floor you would usually place a bottom slab, but with the item you will place a double slab. However the entity collision checking still thinks you are placing a bottom slab allowing you to place the double slab inside yourself when jumping of standing on the edge of a non-full block like for example an enchanting table.
If you aiming at the side of a block with the chain that places a vertical chain and standing like this you can see in this screenshot, you will not be able to place chain even though it wouldn’t be insde you, if you are aiming at the floor however it will work.
This affects every block with any block state that changes the collision box.
Fixed in 17w47a and up.