Add entityAtCursor function

[Chitasa]

No description provided.

[u9g]

needs a lint

[u9g]

shouldnt this be entityAtCursor instead? since you will hit any entity first even if you have a player in range of your cursor?

[Chitasa]

I used bot.players rather than bot.entities so it should only target players.

[u9g]

I used bot.players rather than bot.entities so it should only target players.

why? defeats the purpose of this since if you have a mob infront of the player you wont notice

[Chitasa]

I used bot.players rather than bot.entities so it should only target players.

why? defeats the purpose of this since if you have a mob infront of the player you wont notice

It's mostly because I haven't played around with bounding boxes of other entities (and the use case I had in mind didn't have other entities), but I can always make changes to it so it uses different entities as well.

[Chitasa]

Seeing as there's no changes requested, is there anything I need to do?

[Chitasa]

There seems to be a weird bug in RaycastIterator.intersect where an intersection is detected at

{
  pos: Vec3 {
    x: -1.4554090302898173,
    y: 83.76438681030076,
    z: 6.829271060309972
  },
  face: 3
}

when pos is

{ x: -2, y: 83, z: 3, face: 3 }

Am I just using the function wrong, or is it an actual bug?

[Karang]

There seems to be a weird bug in RaycastIterator.intersect where an intersection is detected at

{
  pos: Vec3 {
    x: -1.4554090302898173,
    y: 83.76438681030076,
    z: 6.829271060309972
  },
  face: 3
}

when pos is

{ x: -2, y: 83, z: 3, face: 3 }

Am I just using the function wrong, or is it an actual bug?

What do you mean ? It's unlikely that the position returned by intersect has only integer coordinates, so the first one seems more legit.
The intersect method returns the exact point of intersection of the bounding box with the ray, not the center of the entity.

[Chitasa]

There seems to be a weird bug in RaycastIterator.intersect where an intersection is detected at

{
  pos: Vec3 {
    x: -1.4554090302898173,
    y: 83.76438681030076,
    z: 6.829271060309972
  },
  face: 3
}

when pos is

{ x: -2, y: 83, z: 3, face: 3 }

Am I just using the function wrong, or is it an actual bug?

What do you mean ? It's unlikely that the position returned by intersect has only integer coordinates, so the first one seems more legit.
The intersect method returns the exact point of intersection of the bounding box with the ray, not the center of the entity.

I'm more focused on the distance between the 2 points rather than the position being only integer coordinates. The first coordinate I posted was the intersection while the second one was the pos returned by RaycastIterator.next() (I probably should have explained that earlier oops). There is an approx 3 block distance between the 2 points, while at most it should be roughly 1-2 blocks, so it really should not be intersecting.

I forgot to mention, but this was primarily looked into cause I noticed the bot was attacking behind itself.

[Karang]

There seems to be a weird bug in RaycastIterator.intersect where an intersection is detected at

{
  pos: Vec3 {
    x: -1.4554090302898173,
    y: 83.76438681030076,
    z: 6.829271060309972
  },
  face: 3
}

when pos is

{ x: -2, y: 83, z: 3, face: 3 }

Am I just using the function wrong, or is it an actual bug?

What do you mean ? It's unlikely that the position returned by intersect has only integer coordinates, so the first one seems more legit.
The intersect method returns the exact point of intersection of the bounding box with the ray, not the center of the entity.

I'm more focused on the distance between the 2 points rather than the position being only integer coordinates. The first coordinate I posted was the intersection while the second one was the pos returned by RaycastIterator.next() (I probably should have explained that earlier oops). There is an approx 3 block distance between the 2 points, while at most it should be roughly 1-2 blocks, so it really should not be intersecting.

I forgot to mention, but this was primarily looked into cause I noticed the bot was attacking behind itself.

Now that i looked the code it makes sense. The 2 pos you are talking about are unrelated.

For the bot attacking behind itself you need to check the sign of the dot product of (pos-eyePosition) and viewDirection

[rom1504]

is this ready @Karang @O-of ?

[Chitasa]

Waiting for @Karang to verify, but it's all right on my part.

[extremeheat]

LGTM, but I think this would be better suited to go into prismarine-world like bot.blockAtCursor.

[extremeheat]

where does the 0.18 constant come from?

[Chitasa]

Adding the 0.18 constant comes is due to this where the bot's height is set to its eye height, 1.62, rather than the bot's actual height 1.80.

[Chitasa]

LGTM, but I think this would be better suited to go into prismarine-world like bot.blockAtCursor.

I thought that bot.blockAtCursor is also in ray_trace.js too?

[rom1504]

this needs docs

[Karang]

LGTM, but I think this would be better suited to go into prismarine-world like bot.blockAtCursor.

I thought that bot.blockAtCursor is also in ray_trace.js too?

pworld doesn't have entities yet, so it makes sense to be in mineflayer for now. can be moved later

[Saiv46]

LGTM

[amoraschi]

Can you also add it in index.d.ts?

[Pix3lPirat3]

One issue I've ran into with this myself (which I just added a blacklist argument for my own purposes) is that it likes to target experience orbs, which may create unwanted results for some users of this function, as you can interact through experience orbs and such.