Deprecate get_objects_inside_radius() API function #6326

New Issue

whosit · 2024-02-21T09:56:13Z

whosit commented

2024-02-21 09:56:13 +00:00

It's used for many things, but there should be better ways to do those. That will require further API additions.

Current uses:

Managing entity attached to a node. Normal entitiy is created, positioned at specific point, and then get_objects_inside_radius used to find it again to change/remove. Used by anvils, armor stands, signs, etc.
Area damage (from explosions, etc) - TNT, cannons etc.
"Collision detection" - fireworks, snowballs, spears
Objects interacting with nodes - pressure plates, portals, detector blocks
Mobs looking for other mobs to interact with (attack, etc)
Limiting mob spawning - various mob libs, vex

How this should be done:
1 - Special API to "parent" entity to a node, so it has same lifetime as the node - gets created/activated/deleted together with node itself, and node would store a reference to entity and entity to node.
2 and 3 should be handled by engine collision detection (even better if it's on_collide callbacks), right now it can be updated to use moveresult instead.
4 - should also use collision detection. Instead of static object constantly polling the world, it should just create a "sensor" volume, that would be handled by collision detection code. Will work nicely with (1).
5 - same "sensor" volume, handled by collision detection.
6 - should be other ways to count/limit, (sensor objects would work too)

It's used for many things, but there should be better ways to do those. That will require further API additions. Current uses: 1. Managing entity attached to a node. Normal entitiy is created, positioned at specific point, and then `get_objects_inside_radius` used to find it again to change/remove. Used by anvils, armor stands, signs, etc. 2. Area damage (from explosions, etc) - TNT, cannons etc. 3. "Collision detection" - fireworks, snowballs, spears 4. Objects interacting with nodes - pressure plates, portals, detector blocks 5. Mobs looking for other mobs to interact with (attack, etc) 6. Limiting mob spawning - various mob libs, vex How this should be done: 1 - Special API to "parent" entity to a node, so it has same lifetime as the node - gets created/activated/deleted together with node itself, and node would store a reference to entity and entity to node. 2 and 3 should be handled by engine collision detection (even better if it's `on_collide` callbacks), right now it can be updated to use `moveresult` instead. 4 - should also use collision detection. Instead of static object constantly polling the world, it should just create a "sensor" volume, that would be handled by collision detection code. Will work nicely with (1). 5 - same "sensor" volume, handled by collision detection. 6 - should be other ways to count/limit, (sensor objects would work too)

👍 1

whosit added the

3. source/engine

label 2024-02-21 09:56:13 +00:00

AliasAlreadyTaken added the

2. prio/interesting

label 2024-02-21 20:26:13 +00:00

flux commented

2024-02-22 00:51:56 +00:00

Managing entity attached to a node.

https://github.com/minetest/minetest/issues/6963

"Collision detection"

this is also currently accomplished by iterating all entities on the server, so i'm not sure what benefit this would give.

> 1. Managing entity attached to a node. https://github.com/minetest/minetest/issues/6963 > "Collision detection" this is also currently accomplished by iterating all entities on the server, so i'm not sure what benefit this would give.

whosit commented

2024-02-22 05:32:01 +00:00

"Collision detection"

this is also currently accomplished by iterating all entities on the server, so i'm not sure what benefit this would give.

Currently, yes, but at least in theory, collision detection would only be run once per server step VS each object doing independent queries at random times.

> > "Collision detection" > > this is also currently accomplished by iterating all entities on the server, so i'm not sure what benefit this would give. Currently, yes, but at least in theory, collision detection would only be run once per server step VS each object doing independent queries at random times.

Sign in to join this conversation.