Add `on_step` callback for Raycast module

[Stoupy51]

🗂️ Request Type

Feature

🧩 Feature or Module Name

#bs.raycast:run

📝 Description

That would be great if there was a new callback called for each step of the raycast process.
So I can use particles for a bullet.

https://docs.mcbookshelf.dev/en/latest/modules/raycast.html

[Stoupy51]

By the way, what is the easiest way to detect headshots?
I believe it might be something to add to https://docs.mcbookshelf.dev/en/latest/modules/hitbox.html

[Stoupy51]

Also, I'd really like those two lines to be inverted:

https://github.com/mcbookshelf/bookshelf/blob/master/modules/bs.raycast/data/bs.raycast/function/collide/entity.mcfunction#L20-L21

Because currently, when an entity is hit, I can't get the hit_point

[aksiome]

On step callback

I'm totally on board with the idea of adding an on_step option. The main challenge, however, is that our current raycast doesn’t run at fixed intervals and it aligns to the grid. To implement true stepping, we'd need to create a new recursive loop that walks the ray with a constant step size. Performance-wise, this would end up being very similar to calling an external recursive function from the target to the origin.

That said, I still think it's worth doing. If we go ahead with it, though, I’m not convinced the name on_step is ideal, since it wouldn’t really reflect the actual raycast steps. We'd also need to add a parameter to control the interval between "steps".

Headshot Detection

For the headshot detection part, I’m thinking of adding eye-level height data to the hitbox module. That way, the user could simply check if the y position is between 2 * eye_level - height and height. That would work for mobs with a centered head.

The issue is, many mobs have heads that are offset, and their apparent hit area changes depending on their rotation. Minecraft’s entity hitboxes are often awkward due to being restricted to a simple width and height, and don’t reflect the actual model very well.
We could define a special "head" hitbox manually for each mob, but that would be fairly arbitrary, based more on visuals than actual collision logic. Also, there are probably around 100 entity types to cover, and updating each by hand would take a lot of time. Not something I’m eager to jump into right now.

What do you think, @theogiraudet? Should we stay faithful to Minecraft’s native hitboxes, or start defining more “accurate” hit regions ourselves?