Fix block visibility calculation using canSeeBlock(block) function

[NoClipMonster]

Changes:
Changed distance calculation from block.position to block.position.offset(0.5, 0.5, 0.5)

The blue line represents the distance calculation to the block's corner (block.position), while the red line shows the direction vector to the block's center (block.position.offset(0.5, 0.5, 0.5)).

The Issue:
When the raycast checks if the bot can see the block along the red path, it uses the distance from the blue line. However, this distance is calculated to the wrong point (corner instead of center), causing the raycast to fail even when the block should be visible.

The Fix:
By changing the distance calculation to block.position.offset(0.5, 0.5, 0.5), we now measure the distance to the block's center, which aligns with the direction vector used in the raycast. This ensures that the distance and direction calculations are consistent, allowing the visibility check to work correctly.

[NoClipMonster]

Before:

After:

[NoClipMonster]

Changes:

New getVisibleBlockFaces() Function:

• Calculates which faces of a block are visible from the bot's current position
• Uses dot product between face normal vectors and observer-to-block vector

Enhanced canSeeBlock() Function:

• Improved the existing block visibility detection logic
• First attempts direct raycast to block center
• If direct raycast fails, tries raycasting to each visible face of the block
• Uses the getVisibleBlockFaces() function to determine which faces to test
• More robust detection for partially obscured blocks

Before:

After:

[extremeheat]

This implementation seems quite inefficient if you're doing multiple raycast within the loop. Also this should likely be implemented in prismarine-world

[Copilot]

Pull Request Overview

This PR fixes block visibility calculation in the canSeeBlock function by ensuring distance calculations use the block's center point rather than its corner. The change aligns the distance measurement with the direction vector used in raycasting, resolving visibility detection issues where blocks should be visible but the check fails.

Key changes:

• Updated distance calculation to use block center coordinates (offset by 0.5, 0.5, 0.5)
• Added comprehensive face-based visibility checking as fallback
• Introduced helper function for determining visible block faces

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[NoClipMonster]

This implementation seems quite inefficient if you're doing multiple raycast within the loop. Also this should likely be implemented in prismarine-world

Performance considerations:

Example:

• Ore search at 32 block distance took 70ms and found 600 blocks
• For all 600 blocks:
  • Algorithm without face visibility check: 6ms
  • Algorithm with face visibility check: 12ms

Yes, this algorithm uses 2 additional raycasts. This is 2x slower, but in the context of bot operation where it can take 5 seconds to find a path to a block, this is negligible compared to the benefits this method provides.

Also, I couldn't find any mention of something similar in prismarine-world or any other module.

I can add an optional skipFaceVisibilityCheck parameter to disable the complex face visibility check when performance is critical.