[B+C] Add Location.getNearbyEntities. Adds BUKKIT-3868

[NathanWolf]

The Issue

There is currently an Entity.getNearbyEntities() method, but no way to perform a similar check on an arbitrary Location without an Entity.

Justification for this PR

This PR adds the Location.getNearbyEntities method requested in BUKKIT-3868, as well as a World.getEntities(Location, x, y, z) method that backs it. These additional utility methods provide a way for developers to efficiently query for entities within a given area, without needing a source Entity.

PR Breakdown

Bukkit

Add Location.getNearbyEntities(double x, double y, double z) and World.getEntities(Location center, double x, double y, double z)

CraftBukkit

CraftWorld implements getEntities similarly to CraftEntity, except it passes in a null source Entity (given current NMS code, this is safe, the entity parameter is only used with "==" to filter out the source entity) and it creates an AABB rather than using a modified Entity BB.

Testing Results and Materials

A test plugin can be found here:

https://github.com/NathanWolf/Bukkit-Unit-Tests/tree/Fix-BUKKIT-3868
http://mine.elmakers.com/share/Test-Fix-BUKKIT-3868.jar

This plugin will search for entities at your target block (block under cursor) when you swing (left-click) a stick or blaze rod.

A stick will check within 8 blocks, a blaze rod within 64. It will print a list of entity counts by type in the area, and can be used to validate that the correct entities are found.

Relevant PR(s)

CB-1384: Bukkit/CraftBukkit#1384 - Associated CB PR

JIRA Ticket

https://bukkit.atlassian.net/browse/BUKKIT-3868

[turt2live]

I would almost say that specifying a bounding box instead of a center with distance on each access would be better. I say this for the sole purpose of being able to call the API without having to potentially translate locations, and it would make implementation in plugins a bit more seamless.

(I hope that made sense. Smartphones should not be used for reviewing prs)

[NathanWolf]

That makes sense to me, and I agree.

I was aiming to implement the interface requested in the BUKKIT-3868 (not my request). It does make sense in the context of Entity.getNearbyEntities().

What about adding a BoundingBox method in addition to the (center, x, y, z)?

[turt2live]

Honestly I thought that was more an offset method, such as "origin, offX,
offY, offZ" , not a center. But I guess that can happen if you don't read
things like variable names.

Either way, I don't think having the method is worthwhile if there was a
bounding box method (two location objects would be fine. No need for a new
class). Having a single method for boxes and a single method for "radius"
should suffice 99% of people. Then again I suppose a center oriented box
may be useful.

sent from mobile
On May 29, 2014 3:55 PM, "Nathan Wolf" notifications@github.com wrote:

That makes sense to me, and I agree.

I was aiming to implement the interface requested in the BUKKIT-3868 (not
my request). It does make sense in the context of
Entity.getNearbyEntities().

What about adding a BoundingBox method in addition to the (center, x, y,
z)?

—
Reply to this email directly or view it on GitHub
#1068 (comment).

[turt2live]

This import is in the wrong spot

[turt2live]

I've created my own testing materials as the ones provided do not operate.

Google Drive