debug get_objects_inside_radius #3723

New Issue

AliasAlreadyTaken · 2023-02-04T13:55:19Z

AliasAlreadyTaken commented

2023-02-04 13:55:19 +00:00

So far, get_objects_inside_radius is always at the top when I watch the server from perf top. THis is only an example, sometimes it goes up to 60%:

  12.92%  minetestserver                   [.] server::ActiveObjectMgr::getObjectsInsideRadius
   4.46%  minetestserver                   [.] Map::isOccluded
   2.23%  minetestserver                   [.] MapSector::getBlockNoCreateNoEx
   1.96%  minetestserver                   [.] Map::getSectorNoGenerateNoLock
   1.95%  minetestserver                   [.] RemoteClient::GetNextBlocks
   1.40%  minetestserver                   [.] server::ActiveObjectMgr::getAddedActiveObjectsAroundPos
   1.34%  minetestserver                   [.] RollbackManager::getSuspectNearness

So I wanted to know what it does (GOIR is short for get_objects_inside_radius):

local old_get_objects_inside_radius = minetest.get_objects_inside_radius

yl_events.debug = false

minetest.get_objects_inside_radius = function(pos,radius)

	if yl_events.debug == false then
		return old_get_objects_inside_radius(pos,radius)
	else
		local t0 = core.get_us_time()
		local from = debug.getinfo(2, "nS")
		local t1 = core.get_us_time()
		local ret = old_get_objects_inside_radius(pos, radius)
		local dt = core.get_us_time()-t1 or 0
		local spos = core.pos_to_string(vector.round(pos)) or ""
		local source = from.source or "unknown"
		local line = from.linedefined or "unknown"
		local dt2 = core.get_us_time()-t0 or 0
		local logme = table.concat({"[DEBUG] GOIR dt=",dt,"/",dt2," at ",spos,", r=",radius," from=",source,"@",line})
		core.log("action",logme)
		return ret
	end
end

For some reason its mainly the pressureplates creating that much lag:

2023-02-04 13:40:16: ACTION[Server]: [DEBUG] GOIR dt=818/847 at (2138,29,1135), r=0.99 from=@/home/mt/5.6.1/Minetest_test/bin/../mods/mesecons/mesecons_pressureplates/init.lua@13

Still, even 500 us is only 0.5 ms, there must be a lot of those around to cause that much lag. However they do not show up in the profiler.

So far, get_objects_inside_radius is always at the top when I watch the server from `perf top`. THis is only an example, sometimes it goes up to 60%: ``` 12.92% minetestserver [.] server::ActiveObjectMgr::getObjectsInsideRadius 4.46% minetestserver [.] Map::isOccluded 2.23% minetestserver [.] MapSector::getBlockNoCreateNoEx 1.96% minetestserver [.] Map::getSectorNoGenerateNoLock 1.95% minetestserver [.] RemoteClient::GetNextBlocks 1.40% minetestserver [.] server::ActiveObjectMgr::getAddedActiveObjectsAroundPos 1.34% minetestserver [.] RollbackManager::getSuspectNearness ``` So I wanted to know what it does (GOIR is short for get_objects_inside_radius): ``` local old_get_objects_inside_radius = minetest.get_objects_inside_radius yl_events.debug = false minetest.get_objects_inside_radius = function(pos,radius) if yl_events.debug == false then return old_get_objects_inside_radius(pos,radius) else local t0 = core.get_us_time() local from = debug.getinfo(2, "nS") local t1 = core.get_us_time() local ret = old_get_objects_inside_radius(pos, radius) local dt = core.get_us_time()-t1 or 0 local spos = core.pos_to_string(vector.round(pos)) or "" local source = from.source or "unknown" local line = from.linedefined or "unknown" local dt2 = core.get_us_time()-t0 or 0 local logme = table.concat({"[DEBUG] GOIR dt=",dt,"/",dt2," at ",spos,", r=",radius," from=",source,"@",line}) core.log("action",logme) return ret end end ``` For some reason its mainly the pressureplates creating that much lag: ``` 2023-02-04 13:40:16: ACTION[Server]: [DEBUG] GOIR dt=818/847 at (2138,29,1135), r=0.99 from=@/home/mt/5.6.1/Minetest_test/bin/../mods/mesecons/mesecons_pressureplates/init.lua@13 ``` Still, even 500 us is only 0.5 ms, there must be a lot of those around to cause that much lag. However they do not show up in the profiler.

AliasAlreadyTaken added the

1. kind/documentation

1. kind/other

3. source/lag

labels 2023-02-04 13:59:04 +00:00

Bla commented

2023-02-04 15:04:36 +00:00

12.92% minetestserver [.] server::ActiveObjectMgr::getObjectsInsideRadius

ActiveObjectMgr sounds more like entities than nodes to me.

For some reason its mainly the pressureplates creating that much lag:

I know mesecons has a setting to control pressureplate check interval with 0.1 as default.
For fun I set it to 0.2 in singleplayer and the difference was barely noticable, even 0.3 wasn´t bad. Curios how noticable it would really be on a busy server

> 12.92% minetestserver [.] server::ActiveObjectMgr::getObjectsInsideRadius `ActiveObjectMgr` sounds more like entities than nodes to me. > For some reason its mainly the pressureplates creating that much lag: I know mesecons has a setting to control pressureplate check interval with 0.1 as default. For fun I set it to 0.2 in singleplayer and the difference was barely noticable, even 0.3 wasn´t bad. Curios how noticable it would really be on a busy server

flux commented

2023-02-04 22:28:31 +00:00

getObjectsInsideRadius is hugely inefficient, and all calls to it will essentially have the same run time, no matter where it is executed and what the radius is or how many entities are actually inside the radius. it's O(n) in the total number of mobs on the server.

this is because it iterates the list of all active mobs and checks whether they're within bounds. because we've got so many active mobs (2500-4500 generally) it takes a relatively large amount of time.

both mobkit and mobs_redo have mobs check their surroundings for potential targets to attack or run away from at regular intervals, so it's a relatively expensive operation that gets called a lot.

what can we do to improve this?

reduce the number of entities. while i am writing this, there are 3907+ entities on the server. 1223 of them are itemframes, 1146 are from signs, 520 are from smartshops, 477 are from signs_lib, 139 are from itemshelves, and 402 others (no other single mod is responsible for more than 68). i've written a script to search for "duplicate" entities (#2234, #2235), and outside of a couple signs, i can't find much.
reduce the number of calls to "get_objects_in_are/get_objects_inside_radius". i'm not sure how feasible this is.
implement better code for "get_objects_in_are/get_objects_inside_radius", e.g. making use of an octree

`getObjectsInsideRadius` is hugely inefficient, and all calls to it will essentially have the same run time, no matter where it is executed and what the radius is or how many entities are actually inside the radius. it's `O(n)` in the total number of mobs on the server. this is because it iterates the list of *all active mobs* and checks whether they're within bounds. because we've got so many active mobs (2500-4500 generally) it takes a relatively large amount of time. both mobkit and mobs_redo have mobs check their surroundings for potential targets to attack or run away from at regular intervals, so it's a relatively expensive operation that gets called *a lot*. what can we do to improve this? 1. reduce the number of entities. while i am writing this, there are 3907+ entities on the server. 1223 of them are itemframes, 1146 are from signs, 520 are from smartshops, 477 are from signs_lib, 139 are from itemshelves, and 402 others (no other single mod is responsible for more than 68). i've written a script to search for "duplicate" entities (#2234, #2235), and outside of a couple signs, i can't find much. 1. reduce the number of calls to "get_objects_in_are/get_objects_inside_radius". i'm not sure how feasible this is. 2. implement better code for "get_objects_in_are/get_objects_inside_radius", e.g. making use of an [octree](https://en.wikipedia.org/wiki/Octree)

flux commented

2023-02-04 22:38:02 +00:00

did some actual performance testing, my comments above might not be great...

depending on the size of the volume/radius, the amount of time it takes to construct the list can range from 100us (r=0) to 500us (r=54000), indicating that creating the list to return is actually more expensive than iterating over all entities and testing them.

also, "get_objects_in_area" and "get_objects_inside_radius" had similar upper/lower bounds

did some actual performance testing, my comments above might not be great... depending on the size of the volume/radius, the amount of time it takes to construct the list can range from 100us (r=0) to 500us (r=54000), indicating that creating the list to return is actually more expensive than iterating over all entities and testing them. also, "get_objects_in_area" and "get_objects_inside_radius" had similar upper/lower bounds

flux commented

2023-02-04 22:51:58 +00:00

however, note that 60% of .044s (server step) corresponds to about 53 get_objects_inside_radius calls...

a rough audit of petz/mobs_redo/mobkit/water_life doesn't show me anything that looks like get_objects_inside_radius getting called even once per step per mob, though.

however, note that 60% of .044s (server step) corresponds to about 53 `get_objects_inside_radius` calls... a rough audit of petz/mobs_redo/mobkit/water_life doesn't show me anything that looks like `get_objects_inside_radius` getting called even once per step per mob, though.

AliasAlreadyTaken commented

2023-03-27 05:03:46 +00:00

For some reason this inspired https://gist.github.com/Niklp09/0bcf6851b7cb9a957711adc2ffb2993e

Sokomine commented

2023-04-08 23:11:20 +00:00

If constructing the list and passing it on as a parameter is a major issue, then an additional paramter to tell the engine to only search for objects that are known to actually move (mostly mobs, players, and - far less intresting - items in tubes) might be intresting.

flux commented

2023-04-09 00:11:34 +00:00

If constructing the list and passing it on as a parameter is a major issue

it can be if there's actually a ton of mobs within the region, but in our case, the run-time scales more because of the # of entities on the server, than the # of entities in the area.

data structures exist for keeping track of the position of objects in 3d, both calls should be O(log(n)) instead of O(n) in the # of entities on the server. the calls are taking possibly 100s of times longer than they ought to.

> If constructing the list and passing it on as a parameter is a major issue it can be if there's actually a ton of mobs within the region, but in our case, the run-time scales more because of the # of entities on the server, than the # of entities in the area. data structures exist for keeping track of the position of objects in 3d, both calls should be `O(log(n))` instead of `O(n)` in the # of entities on the server. the calls are taking possibly 100s of times longer than they ought to.

flux commented

2023-04-15 00:31:18 +00:00

i was curious, so i ran some tests.

local clock = os.clock
local function test(trials, func, ...)
 local start = clock()
 for i = 1, trials do
  func(...)
 end
 return clock() - start
end 

local trials = 1000
local goia = minetest.get_objects_in_area
local pmin1, pmax1 = vector.new(0, 0, 0), vector.new(0, 0, 0)
local pmin2, pmax2 = vector.new(-30912, -30912, -30912), vector.new(30927, 30927, 30927)
print(#goia(pmin2, pmax2))
print(math.round(1e6 * test(trials, goia, pmin1, pmax1)))
print(math.round(1e6 * test(trials, goia, pmin2, pmax2)))

the first test matches no objects (usually). the second test matches every object. with 5122 active on the server, the first test took 1/4 of the time of the second, which is a sizable overhead.

i was curious, so i ran some tests. ```lua local clock = os.clock local function test(trials, func, ...) local start = clock() for i = 1, trials do func(...) end return clock() - start end local trials = 1000 local goia = minetest.get_objects_in_area local pmin1, pmax1 = vector.new(0, 0, 0), vector.new(0, 0, 0) local pmin2, pmax2 = vector.new(-30912, -30912, -30912), vector.new(30927, 30927, 30927) print(#goia(pmin2, pmax2)) print(math.round(1e6 * test(trials, goia, pmin1, pmax1))) print(math.round(1e6 * test(trials, goia, pmin2, pmax2))) ``` the first test matches no objects (usually). the second test matches every object. with 5122 active on the server, the first test took 1/4 of the time of the second, which is a sizable overhead.

flux commented

2023-06-18 22:00:31 +00:00

i made a new mod which uses a binary search tree to more efficiently get objects in area/radius https://github.com/fluxionary/minetest-oia

though because it's in lua and not c++, the overhead means it's not efficient until there's around 1000 active entities. it does seem like it'd provide a performance benefit for your-land though.

i made a new mod which uses a binary search tree to more efficiently get objects in area/radius https://github.com/fluxionary/minetest-oia though because it's in lua and not c++, the overhead means it's not efficient until there's around 1000 active entities. it does seem like it'd provide a performance benefit for your-land though.

AliasAlreadyTaken commented

2023-06-18 23:21:48 +00:00

Let's throw it onto the testserver?

flux commented

2023-06-19 01:23:04 +00:00

Let's throw it onto the testserver?

i've done some more testing and ... it's not so cut-and dried. oia under-performs if there's hundreds or more active objects within the relevant area. also, i've discovered that enabling the "override builtin functionality" feature causes multiple issues w/ other mods, for reasons i'm not quite sure about (it seems that the 3d armor stand will keep trying to re-create an object if it can't find itself immediately after creation?)

also, this sort of performance-related functionality is hard to test w/out a lot of players loading a lot of areas w/ a lot of mobs.

in one test, it sped things up by almost 100x. in another, it slowed things down by about 20x.

there's still potential here, but it needs more tweaking. also, probably, i should try to actually code it up in c++ in the engine, now that i've got some data that the approach is successful.

> Let's throw it onto the testserver? i've done some more testing and ... it's not so cut-and dried. oia under-performs if there's hundreds or more active objects within the relevant area. also, i've discovered that enabling the "override builtin functionality" feature causes multiple issues w/ other mods, for reasons i'm not quite sure about (it seems that the 3d armor stand will keep trying to re-create an object if it can't find itself immediately after creation?) also, this sort of performance-related functionality is hard to test w/out a lot of players loading a lot of areas w/ a lot of mobs. in one test, it sped things up by almost 100x. in another, it slowed things down by about 20x. there's still potential here, but it needs more tweaking. also, probably, i should try to actually code it up in c++ in the engine, now that i've got some data that the approach is successful.

whosit commented

2023-06-19 06:40:28 +00:00

also, this sort of performance-related functionality is hard to test w/out a lot of players loading a lot of areas w/ a lot of mobs.

This is relevant:
your-land/administration#188

Or, more simple way is using world-loading-anchors...

We should count which mods use get_objects_inside_radius and create a script that places anchors and spawns mobs/whatever trying to simulate the YL.

Also would be interesting to get log like this:

2023-02-04 13:40:16: ACTION[Server]: [DEBUG] GOIR dt=818/847 at (2138,29,1135), r=0.99 from=@/home/mt/5.6.1/Minetest_test/bin/../mods/mesecons/mesecons_pressureplates/init.lua@13

and plot it on the map, coloring points by mod for example... Could help making anchor simulation closer to reality.

in one test, it sped things up by almost 100x. in another, it slowed things down by about 20x.

Since you recreate whole tree on the fly anyway, you could dynamically switch it on and off, but:

also, probably, i should try to actually code it up in c++ in the engine

Fixing the engine seems like the most sane way to do this. I feel like even something minimal that just uses 2d sparse grid (ignoring the Y-coord) or a sorted list should increase performance...

> also, this sort of performance-related functionality is hard to test w/out a lot of players loading a lot of areas w/ a lot of mobs. This is relevant: https://gitea.your-land.de/your-land/administration/issues/188 Or, more simple way is using world-loading-anchors... We should count which mods use `get_objects_inside_radius` and create a script that places anchors and spawns mobs/whatever trying to simulate the YL. Also would be interesting to get log like this: ``` 2023-02-04 13:40:16: ACTION[Server]: [DEBUG] GOIR dt=818/847 at (2138,29,1135), r=0.99 from=@/home/mt/5.6.1/Minetest_test/bin/../mods/mesecons/mesecons_pressureplates/init.lua@13 ``` and plot it on the map, coloring points by mod for example... Could help making anchor simulation closer to reality. > > in one test, it sped things up by almost 100x. in another, it slowed things down by about 20x. Since you recreate whole tree on the fly anyway, you could dynamically switch it on and off, but: > also, probably, i should try to actually code it up in c++ in the engine Fixing the engine seems like the most sane way to do this. I feel like even something minimal that just uses 2d sparse grid (ignoring the Y-coord) or a sorted list should increase performance...

AliasAlreadyTaken added the

3. source/engine

label 2023-07-21 14:27:34 +00:00

whosit referenced this issue

2023-07-23 12:55:53 +00:00

Chache reports: We have discovered there is no ... #4988

sixer commented

2023-07-23 13:22:33 +00:00

Fixing the engine seems like the most sane way to do this. I feel like even something minimal that just uses 2d sparse grid (ignoring the Y-coord) or a sorted list should increase performance...

Exactly. Note that any kind of reasonable structure may slightly increase cost of updating object's position (i.e. possibly migrating to a different leaf in octree, possibly having to rebalance the tree occasionally.), although that overhead will not be large in average.

Currently the objects are stored in unordered map, keyed by their ID.

> Fixing the engine seems like the most sane way to do this. I feel like even something minimal that just uses 2d sparse grid (ignoring the Y-coord) or a sorted list should increase performance... Exactly. Note that any kind of reasonable structure may slightly increase cost of updating object's position (i.e. possibly migrating to a different leaf in octree, possibly having to rebalance the tree occasionally.), although that overhead will not be large in average. Currently the objects are stored in unordered map, keyed by their ID.

flux commented

2023-07-24 05:08:38 +00:00

Fixing the engine seems like the most sane way to do this. I feel like even something minimal that just uses 2d sparse grid (ignoring the Y-coord) or a sorted list should increase performance...

reducing the "nearness" issue from 3d to 2d doesn't buy us much in terms of data structure complexity. metrics on more than 1 dimension don't "sort" naturally.

> Fixing the engine seems like the most sane way to do this. I feel like even something minimal that just uses 2d sparse grid (ignoring the Y-coord) or a sorted list should increase performance... reducing the "nearness" issue from 3d to 2d doesn't buy us much in terms of data structure complexity. metrics on more than 1 dimension don't "sort" naturally.

flux referenced this issue

2023-07-24 05:24:15 +00:00

OOM #4943

flux commented

2023-07-24 05:29:53 +00:00

i've got a couple papers to read and some experimentation, but i do think it'd be possible to create a self-balancing kd-tree, though it won't have ideal performance characteristics. the trick then becomes implementing it in c++ and getting the engine folks to use it

AliasAlreadyTaken commented

2023-07-24 20:40:20 +00:00

Could we replace get_objects_inside_radius with a cheaper tech?

All functions that aim to detect players could instead use a "detect_player_in_radius", which is probably much cheaper. Especially if we cache the player pos once and update only after each step.

We found pressure plates terribly expensive. They fire each 0.1s ? Would they stop working if we made them detect only every 0.3s ?

Could we replace get_objects_inside_radius with a cheaper tech? All functions that aim to detect players could instead use a "detect_player_in_radius", which is probably much cheaper. Especially if we cache the player pos once and update only after each step. We found pressure plates terribly expensive. They fire each 0.1s ? Would they stop working if we made them detect only every 0.3s ?

sixer commented

2023-07-24 21:17:38 +00:00

We found pressure plates terribly expensive. They fire each 0.1s ? Would they stop working if we made them detect only every 0.3s ?

Yes. Especially if people sprint over them with crystal boots.

Replacing object detection with player detection would be cheap way to regain performance ... unless it breaks something. Are pressure plates supposed to react only on players, or should they trigger for mobs too?

> We found pressure plates terribly expensive. They fire each 0.1s ? Would they stop working if we made them detect only every 0.3s ? Yes. Especially if people sprint over them with crystal boots. Replacing object detection with player detection would be cheap way to regain performance ... unless it breaks something. Are pressure plates supposed to react only on players, or should they trigger for mobs too?

whosit commented

2023-07-24 22:05:10 +00:00

i've got a couple papers to read and some experimentation, but i do think it'd be possible to create a self-balancing kd-tree, though it won't have ideal performance characteristics. the trick then becomes implementing it in c++ and getting the engine folks to use it

Do kd-trees fit this use case? It seems like they are mostly used for static objects? If moving one object sometimes will trigger rebalancing of a large part of the tree and sometimes be quick, then such uneven load is not good for a realtime game (I guess this may be what you mean by "not ideal performance characteristics"?). Or are you planning to just rebuild it each timestep?

Maybe we should learn from existing game engines...

Could we replace get_objects_inside_radius with a cheaper tech?
We found pressure plates terribly expensive.

In some other games stuff like this is done via collision callbacks, and instead of querying objects_in_radius, you just have a sphere that other objects will "collide" with. In case of a pressure plate - if it does not move, and nothing moved around it, then you don't need to call any special pressure plate code at all.

> i've got a couple papers to read and some experimentation, but i do think it'd be possible to create a self-balancing kd-tree, though it won't have ideal performance characteristics. the trick then becomes implementing it in c++ and getting the engine folks to use it Do kd-trees fit this use case? It seems like they are mostly used for static objects? If moving one object sometimes will trigger rebalancing of a large part of the tree and sometimes be quick, then such uneven load is not good for a realtime game (I guess this may be what you mean by "not ideal performance characteristics"?). Or are you planning to just rebuild it each timestep? Maybe we should learn from existing game engines... > Could we replace get_objects_inside_radius with a cheaper tech? > We found pressure plates terribly expensive. In some other games stuff like this is done via collision callbacks, and instead of querying objects_in_radius, you just have a sphere that other objects will "collide" with. In case of a pressure plate - if it does not move, and nothing moved around it, then you don't need to call any special pressure plate code at all.

sixer commented

2023-07-24 23:17:45 +00:00

Do kd-trees fit this use case? It seems like they are mostly used for static objects? If moving one object sometimes will trigger rebalancing of a large part of the tree and sometimes be quick, then such uneven load is not good for a realtime game (I guess this may be what you mean by "not ideal performance characteristics"?). Or are you planning to just rebuild it each timestep?

Rebuild each timestep? Well, with that approach you can go back to searching whole list each time :)

kd-tree are mostly for static objects. What we'll have probably here are players scattered somewhat randomly across world (perhaps with larger density towards haven) and the active objects mostly in some clumps around each of the players and across world anchors (not sure if those are used here at all).

We could have sparse map of sectors (perhaps 80x80x80 aligned to mapchunks) and maintain list of object IDs in each of the sector (most sectors would not be in the map, if the sector gets empty, it is deleted, there would likely be roughly 8 sectors per player at a given time?). Looking at objects in vicinity of some point would likely end up looking at single sector or maybe 2/4/8 of them if near edge or corner. After moving each object, we need to check if it has not crossed the boundary (that would not happen too often in average) and if yes, move it to new sector.

For large ranges (>38) - those would probably be limited to some staff/admin commands, usual items or commands would work with smaller ranges, you can resort back to "search whole list" approach.

Maybe we should learn from existing game engines...

Could we replace get_objects_inside_radius with a cheaper tech?
We found pressure plates terribly expensive.

In some other games stuff like this is done via collision callbacks, and instead of querying objects_in_radius, you just have a sphere that other objects will "collide" with. In case of a pressure plate - if it does not move, and nothing moved around it, then you don't need to call any special pressure plate code at all.

The plate could be optimized to skip few next callbacks if at last callback nothing applicable was near it. But once the player (or mob?) approaches its vicinity, frequent step would be necessary for reliable step-on detection.

> Do kd-trees fit this use case? It seems like they are mostly used for static objects? If moving one object sometimes will trigger rebalancing of a large part of the tree and sometimes be quick, then such uneven load is not good for a realtime game (I guess this may be what you mean by "not ideal performance characteristics"?). Or are you planning to just rebuild it each timestep? Rebuild each timestep? Well, with that approach you can go back to searching whole list each time :) kd-tree are mostly for static objects. What we'll have probably here are players scattered somewhat randomly across world (perhaps with larger density towards haven) and the active objects mostly in some clumps around each of the players and across world anchors (not sure if those are used here at all). We could have sparse map of sectors (perhaps 80x80x80 aligned to mapchunks) and maintain list of object IDs in each of the sector (most sectors would not be in the map, if the sector gets empty, it is deleted, there would likely be roughly 8 sectors per player at a given time?). Looking at objects in vicinity of some point would likely end up looking at single sector or maybe 2/4/8 of them if near edge or corner. After moving each object, we need to check if it has not crossed the boundary (that would not happen too often in average) and if yes, move it to new sector. For large ranges (>38) - those would probably be limited to some staff/admin commands, usual items or commands would work with smaller ranges, you can resort back to "search whole list" approach. > Maybe we should learn from existing game engines... > > > > Could we replace get_objects_inside_radius with a cheaper tech? > > We found pressure plates terribly expensive. > > In some other games stuff like this is done via collision callbacks, and instead of querying objects_in_radius, you just have a sphere that other objects will "collide" with. In case of a pressure plate - if it does not move, and nothing moved around it, then you don't need to call any special pressure plate code at all. The plate could be optimized to skip few next callbacks if at last callback nothing applicable was near it. But once the player (or mob?) approaches its vicinity, frequent step would be necessary for reliable step-on detection.

flux commented

2023-07-26 02:12:58 +00:00

Could we replace get_objects_inside_radius with a cheaper tech?

All functions that aim to detect players could instead use a "detect_player_in_radius", which is probably much cheaper. Especially if we cache the player pos once and update only after each step.

We found pressure plates terribly expensive. They fire each 0.1s ? Would they stop working if we made them detect only every 0.3s ?

iterating all players in lua is definitely cheaper than iterating all mobs in c++. but pressure plates aren't the biggest offenders are they?

> Could we replace get_objects_inside_radius with a cheaper tech? > > All functions that aim to detect players could instead use a "detect_player_in_radius", which is probably much cheaper. Especially if we cache the player pos once and update only after each step. > > We found pressure plates terribly expensive. They fire each 0.1s ? Would they stop working if we made them detect only every 0.3s ? iterating all players in lua is definitely cheaper than iterating all mobs in c++. but pressure plates aren't the biggest offenders are they?

flux referenced this issue

2023-08-18 16:39:49 +00:00

nil check on get_luaentity() #3601

Sign in to join this conversation.