MC-248786Targeting blocks which extend outside of their space fails, causing the underlying block to be targeted instead
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as its entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head wasn't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs.
This list details most of the known cases; there are likely more that existed (one being moving pistons).
Offset dripstone case (MC-206643)
Resulted from the since-fixed MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
Linked Issues
LowAttachments19
Created Issue:
Targeting blocks is fundamentally flawed - parts extending outside of its space are ignored
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as tis entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head weren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A list will be added here in future.
Attachments6
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as tis entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head weren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue.
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as tis entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head weren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as tis entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head weren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as intended: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as tis entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head weren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as
intended: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as tis entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head weren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as
tis entity collision shape and visual wireframe, can extend outside of this space.Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head weren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as its entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head weren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as its entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head w
eren't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as its entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head wasn't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs. A more complete list will be added here in future.
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
Targeting blocksis fundamentally flawed - partsextendingoutside of its spaceare ignoredTargeting blocks which extend outside of its space instead targets the block next to it
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Targeting blocks which extend outside ofitsspaceinstead targets the block next to itTargeting blocks which extend outside of their space fails, causing the underlying block to be targeted instead
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as its entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head wasn't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs.
A more complete list will be added here in future.Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
This ticket is intended to explain the core issue behind MC-124459 and MC-158827, as these two tickets are a result of this main issue.
The bug
The interaction box (i.e. the parts of a block that cause the wireframe outline to display when targeted, indicating it can be broken, placed on, etc.) is physically incapable of extending outside of the 1x1x1 region in which the block itself exists.
This is despite the fact that other block "hitboxes", such as its entity collision shape and visual wireframe, can extend outside of this space.
Current manifestations
This bug is responsible for the effects of the following two bugs:
- MC-124459: Far regions of extended piston heads' arms cannot be targeted
- MC-158827: Opened shulker box lids, as well as the tops of lecterns, cannot be targeted
In both of these cases, targeting regions of blocks that can actually be targeted will show the wireframe hitbox to extend outside of the 1x1x1 region of the block. The issue arises when attempting to actually target these "outside-of-the-block-space" regions, particularly in a way that causes another block to be targeted were that block to not exist.
How to reproduce
Reproduction steps exist in the two sub-issues, but are summarized here anyway.
Piston case
- Place down a piston
- Power the piston
- Target a part of the piston shaft close to the head, noting how the wireframe hitbox extends all the way to the main body of the piston
- Target a part of the piston shaft closer to the body, and note that you're actually targeting the block behind it, as if the head wasn't there
Lectern case
- Place a lectern sideways against a wall
- Target this lectern and note the topmost region of the wireframe
- Aim the crosshair near the top of this wireframe, and notice you're actually highlighting the wall
Shulker box case
- Open a shulker box which is beside a wall
- Notice how the shulker box's wireframe expands to fit its opened state
- When exiting the shulker box, shift your aim upwards as to try and catch the top of the shulker box as it closes, noticing you're again targeting the wall
Expected results
When targeting parts of the wireframe extending outside of the block, the game would still consider the player as targeting the block that wireframe comes from.
Actual results
Parts of the wireframe outside of the block are completely ignored.
Historical manifestations
Several older bugs prove that this bug has existed for well over a decade, having shown itself in many different situations, commonly alongside other bugs.
This list details most of the known cases; there are likely more that existed (one being moving pistons).
Offset dripstone case (
MC-206643)Resulted from the since-fixed
MC-206615. Pointed dripstones with sufficiently-offset hitboxes would demonstrate this issue. Was fixed quickly after in 20w49a.
Cakes/cacti float precision loss case
Up until 15w38a, cakes and cacti used or casted to a float for their hitbox shape. As a result, travelling far enough distances from the world origin results in these blocks either getting tiny or huge hitbox sizes, which allow this effect to be seen.
Overeaten cakes/overgrown stems case
Up until 14w26a, many blocks could be given exceptional data values that the game would just run with despite being functionally invalid. For cakes, melon stems and pumpkin stems, the hitbox size was dynamically created, and had the potential to extend outside of its block space, allowing for this effect to once again be seen:
Expected behaviour: Infdev signs
Our last historical case of large block hitboxes happens way back in the June 7th build of Infdev, with signs, and unlike all of the other examples shown here, they work completely as expected: the parts of the hitbox outside of the area the block occupies are completely targetable. I've also placed a block inside of the top region of the sign to prove the sign isn't like this due to being a multiblock structure like a door is, but instead is a single block which is completely unaffected by this issue. I'm not sure if some optimization happened between inf-20100607 (the version with these signs) and Alpha v1.0.11 (the first version with the cactus issue) that resulted in this bug arising first, or if this bug was spotted for signs and a block-specific fix was implemented. Nonetheless, the sign here is what the piston head, shulker box and lectern should behave like in modern Minecraft.
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
Affects 1.18.2-pre3; I've opened MC-248786 to cover the core issue responsible for this problem.
Affects 1.18.2-pre3; I've opened MC-248786 to cover the core issue responsible for this problem.
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Would MC-248786 describe this issue?
@Jiingy not exactly. If we are talking about the dripstone case, in MC-248786 it's out of the block, but not out of its hitbox.
When writing bug titles, please avoid making commentary on the state of the code, and instead list the impact this has on gameplay.
"Fundamentally flawed" is commentary.
This was inspired by
MC-21109but thanks for the heads up.This could be resolved by making the raycast target 6x6x6, this should contain the largest model with the biggest rotation offset.
Part of me wonders if fences were responsible for this due to their intentionally larger entity collision box but smaller wireframe hitbox. Since cacti were subject to the hitboxes stretching in prior versions I may have to test this in future.
Regardless no longer relevant, as collision and hit boxes are separate, just look at the lectern (top's collision is flat, rather than staircase)
Would you consider
MC-118394to be related to or duplicate this issue?No, that's about not interacting with entity inside the player first, this is about block hitboxes not being targeted if it's outside the block space.