MC-158827Lectern and shulker box hitbox extends beyond 1x1x1 cube
The bug
The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
This also affects extended shulker boxes and piston heads (see MC-124459), as stated by [Helper] Misode in this comment.
Linked Issues
![[Helper] Misode](../../../data/avatars/users/93314.png){kind=small}
Created Issue:
Lectern Hitbox Extends Beyond 1x1x1 Cube
The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
Attachments2
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
Low![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
LecternHitboxExtendsBeyond 1x1x1CubeLectern hitbox extends beyond 1x1x1 cube
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mod] SPGoding](../../../data/avatars/users/44622.png){kind=small}
The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
This also affects extended shulker boxes.
The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
This also affects extended shulker boxes.
The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
This also affects extended shulker boxes and piston heads, as stated by [Helper] Misode in this comment.
The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
This also affects extended shulker boxes and piston heads
, as stated by[Helper] Misodein this comment.The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
This also affects extended shulker boxes and piston heads (see MC-124459), as stated by [Helper] Misode in this comment.
Lectern and shulker box hitbox extends beyond 1x1x1 cube
relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
This also affects extended shulker boxes and piston heads (see MC-124459), as stated by [Helper] Misode in this comment.
The bug
The hitbox for the lectern extends above the top of its 1x1x1 cube, meaning that raycasting never collides with it, even though it should.
See screenshots.
- 19.19.38 shows my cursor pointing at the lectern visual model and the lectern not being selected.
- 19.19.42 shows my cursor pointing low enough to hit the lectern and the raycast volume being shown to extend to the top of the visual model (i.e. above the point my cursor was pointing at in 19.19.38).
This is likely due to optimizations made in the raycasting method that assume all voxel shapes are contained within the 1x1x1 cube, even if those shapes extend beyond (in any direction).
This also affects extended shulker boxes and piston heads (see MC-124459), as stated by [Helper] Misode in this comment.
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
relates to
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mod] Greymagic27](../../../data/avatars/users/92875.png){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
relates to
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.
Duplicate of MC-158827.
Thank you for your report!
We're tracking this issue in MC-158827, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Confirmed for 1.15.1.
Also affects shulker boxes and piston heads.
Can confirm in 20w49a.
Can confirm in 21w03a.
Can confirm in 21w06a.
Can confirm in 1.17.
Can confirm in 1.17.1.
Can confirm in 1.18.1.
Affects 1.18.2-pre3; I've opened MC-248786 to cover the core issue responsible for this problem.
Can confirm in 1.18.2 and 22w16b.
Wouldn't a better title be "Raycasting for block hitbox only checks in 1x1x1 block space, missing some blocks whose hitbox is bigger"?
EDIT: nvm, that's the above linked report.
Can confirm in 1.19.