MC-76493Able to hit a block behind out of range entity.
If you try to hit a silverfish or endermite from 2 blocks directly above it, you will hit the block below it instead. This only occurs in survival mode.
Environment
Operating system: OSX 10.9.5
Java Version: 1.6.0_65
Low
Normal
Created Issue:
Silverfish and endermites can't be hit from 2 blocks above
If you try to hit a silverfish or endermite from 2 blocks directly above it, you will hit the block below it instead. This only occurs in survival mode.
Environment
Operating system: OSX 10.9.5
Java Version: 1.6.0_65
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)Silverfish and endermites can'tbehit from 2 blocks aboveAble to hit a block behind out of range entity.
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
relates to
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
relates to
Code check, yes, there is definitely a difference between the two:
- The logic to determine what block is currently being looked at happens in EntityRenderer.getMouseOver, in a profiler section named "pick". It first gets the player's reach distance using PlayerController.getBlockReachDistance, which returns 5.0 if the player is in creative and 4.5 otherwise. A ray trace is performed using Entity.rayTrace, ray tracing from the eye position to a position calculated with a vector in the direction of the look vector and with a magnitude of the block reach distance. That ray trace is done via World.rayTraceBlocks(Vec3d, Vec3d, boolean, boolean, Boolean), which is convoluted and I'm not going to try to explain. Then, back in EntityRenderer.getMouseOver, there follows some weirdly written logic (probably from recompilation) regarding reach distance if the looked entity is too far away (further changing the distance, limiting it to 3 in a weird way if in survival - probably the due to the way
MC-76493was fixed), but we don't care about entities and this bug still happens when entities aren't a factor. TLDR, for the client, a ray trace from the eyes in the look direction is performed with a max length of the reach distance. - The server's logic, found in NetHandlerPlayServer.processPlayerDigging, computes the square distance from the center of the block (each coordinate in the block position has .5 added to it), to the player's position, using the feet position plus 1.5 as the y coordinate. If that distance is greater than 36 (or the block position is above the world height limit), the action is rejected. It does not seem like any resending occurs when it is rejected there. Further processing is then done, and if the digging state is STOP_DESTROY_BLOCK, PlayerInteractionManager.blockRemoving is called. That does some checking that seems to be for if the block was fully mined, and then calls PlayerInteractionManager.tryHarvestBlock. There isn't any other distance-based checking. Note that, at that point, back in NetHandlerPlayServer.processPlayerDigging, if the block is not air after calling blockRemoving, a setblock packet is sent.
So, there is a discrepancy. However, the server logic is more lenient (6 blocks rather than 4.5), so that probably isn't the cause. If that is the cause, though, then it would make sense since the block is not reverted. Yet I've had it happen (or at least I think I've had it happen) where it's a block near me that failed to break, not a distant one.
Took a while to find it, but this is almost certainly caused by the fix to MC-76493.
Can confirm, although using F3+B to reveal a mob's hitbox, you still can't hit them. (Silverfish and Endermite)
Working as intended. Your interaction range is lower than the block-interaction range. When aiming at something that you cannot interact with however we now make sure you cannot reach the block behind it.