your-land/bugtracker
your-land/bugtracker
40
21
Issues 3.6k Projects 4 Wiki

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

New Issue
Closed
opened 2023-07-23 12:30:47 +02:00 by yourland-report · 20 comments
yourland-report commented 2023-07-23 12:30:47 +02:00
Member
Copy Link

Chache reports a bug:

We have discovered there is no limit for the detection radius of an entity detector. We know of at least one player who has one such detector set to radius 5000, and claims it's working (he can detect Vocie attacks in other cities!). Whosit theorises detectors with such a long range could overload the server. Further experimentation needed.

Player position:

{
	x = 2964,
	y = 1.5,
	z = -2701
}

Player look:

{
	x = 0.84712874889374,
	y = -0.52814197540283,
	z = 0.058642592281103
}

Player information:

{
	lang_code = "es",
	major = 5,
	version_string = "5.6.1",
	formspec_version = 6,
	min_rtt = 0.029999999329448,
	avg_rtt = 0.032000001519918,
	min_jitter = 0,
	max_jitter = 2.7639999389648,
	avg_jitter = 0.00099999830126762,
	max_rtt = 3.0980000495911,
	patch = 1,
	state = "Active",
	protocol_version = 41,
	ip_version = 6,
	connection_uptime = 7431,
	serialization_version = 29,
	minor = 6
}

Player meta:

{
	fields = {
		played_time = "8658602",
		digged_nodes = "957262",
		placed_nodes = "436806",
		died = "12",
		crafted = "114671",
		yl_commons_player_created = "1645471717",
		yl_commons_player_joined = "1690100832",
		jointime = "1645471717",
		bitten = "0",
		["signslib:pos"] = "(3064,17,-2765)",
		["stamina:poisoned"] = "no",
		xp_redo_hud_color = "0xFFFF00",
		repellant = "0",
		punch_count = "38672",
		xp = "1109664",
		inflicted_damage = "1384520",
		["ocean_build.forbidden"] = "true",
		partychat = "party",
		yl_commons_thankyou = "177",
		["3d_armor_inventory"] = "return {\"3d_armor:chestplate_crystal 1 4100\", \"3d_armor:helmet_nether 1 4100\", \"3d_armor:leggings_crystal 1 4100\", \"shields:shield_rainbow 1 1640\", \"3d_armor:boots_crystal 1 4100\", \"\"}",
		["ocean_build.ocean_built"] = "12",
		yl_church = "return {[\"last_death\"] = {[\"x\"] = 3629, [\"y\"] = -4, [\"z\"] = 1614}, [\"last_death_portal\"] = 1682897352, [\"last_heal\"] = 1653594577}",
		hud_state = "on",
		["stamina:level"] = "16",
		["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}",
		arenalib_infobox_arenaID = "0",
		["ocean_build.last_warning"] = "1.65606e+09",
		["stamina:exhaustion"] = "74"
	}
}

Log identifier


[MOD] yl_report log identifier = zbTTqf0heC8xWRfbDaVRykLr6NGt5Al0

Profiler save:

profile-20230723T103047.json_prettyEE

Status:

# Server: version: 5.7.0-yl-thx-tmm | game: Minetest Game | uptime: 16h 53min 50s | max lag: 0.545s | clients (22/52): 9T9, abetovacina, Aero, Amun, Azelf, Bailiff, BibaBoba, Bingo, Chache, daydream, JeCel, JeogreIII, KittyMiau, LadyPixels, Murmel, niceride, NodeBreaker, Penelopee, Shadow, Sysmatic, Wanchor, whosit

Teleport command:

/teleport xyz 2964 2 -2701

Compass command:

/give_compass Construction zbTTqf0heC8xWRfbDaVRykLr6NGt5Al0 D2691E 2964 2 -2701
Chache reports a bug: > We have discovered there is no limit for the detection radius of an entity detector. We know of at least one player who has one such detector set to radius 5000, and claims it's working (he can detect Vocie attacks in other cities!). Whosit theorises detectors with such a long range could overload the server. Further experimentation needed. Player position: ``` { x = 2964, y = 1.5, z = -2701 } ``` Player look: ``` { x = 0.84712874889374, y = -0.52814197540283, z = 0.058642592281103 } ``` Player information: ``` { lang_code = "es", major = 5, version_string = "5.6.1", formspec_version = 6, min_rtt = 0.029999999329448, avg_rtt = 0.032000001519918, min_jitter = 0, max_jitter = 2.7639999389648, avg_jitter = 0.00099999830126762, max_rtt = 3.0980000495911, patch = 1, state = "Active", protocol_version = 41, ip_version = 6, connection_uptime = 7431, serialization_version = 29, minor = 6 } ``` Player meta: ``` { fields = { played_time = "8658602", digged_nodes = "957262", placed_nodes = "436806", died = "12", crafted = "114671", yl_commons_player_created = "1645471717", yl_commons_player_joined = "1690100832", jointime = "1645471717", bitten = "0", ["signslib:pos"] = "(3064,17,-2765)", ["stamina:poisoned"] = "no", xp_redo_hud_color = "0xFFFF00", repellant = "0", punch_count = "38672", xp = "1109664", inflicted_damage = "1384520", ["ocean_build.forbidden"] = "true", partychat = "party", yl_commons_thankyou = "177", ["3d_armor_inventory"] = "return {\"3d_armor:chestplate_crystal 1 4100\", \"3d_armor:helmet_nether 1 4100\", \"3d_armor:leggings_crystal 1 4100\", \"shields:shield_rainbow 1 1640\", \"3d_armor:boots_crystal 1 4100\", \"\"}", ["ocean_build.ocean_built"] = "12", yl_church = "return {[\"last_death\"] = {[\"x\"] = 3629, [\"y\"] = -4, [\"z\"] = 1614}, [\"last_death_portal\"] = 1682897352, [\"last_heal\"] = 1653594577}", hud_state = "on", ["stamina:level"] = "16", ["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}", arenalib_infobox_arenaID = "0", ["ocean_build.last_warning"] = "1.65606e+09", ["stamina:exhaustion"] = "74" } } ``` Log identifier ``` [MOD] yl_report log identifier = zbTTqf0heC8xWRfbDaVRykLr6NGt5Al0 ``` Profiler save: ``` profile-20230723T103047.json_prettyEE ``` Status: ``` # Server: version: 5.7.0-yl-thx-tmm | game: Minetest Game | uptime: 16h 53min 50s | max lag: 0.545s | clients (22/52): 9T9, abetovacina, Aero, Amun, Azelf, Bailiff, BibaBoba, Bingo, Chache, daydream, JeCel, JeogreIII, KittyMiau, LadyPixels, Murmel, niceride, NodeBreaker, Penelopee, Shadow, Sysmatic, Wanchor, whosit ``` Teleport command: ``` /teleport xyz 2964 2 -2701 ``` Compass command: ``` /give_compass Construction zbTTqf0heC8xWRfbDaVRykLr6NGt5Al0 D2691E 2964 2 -2701 ```
AliasAlreadyTaken was assigned by yourland-report 2023-07-23 12:30:47 +02:00
whosit commented 2023-07-23 12:58:33 +02:00
Member
Copy Link

Setting up a detector at Haven (on the test server, hi Bla!) with radius set to 40000, then dropping an item at Atlantis successfully detects it.

Even if this is not linked to OOM, probably should be limited.

Setting up a detector at Haven (on the test server, hi Bla!) with radius set to 40000, then dropping an item at Atlantis successfully detects it. Even if this is not linked to OOM, probably should be limited.
sixer commented 2023-07-23 14:38:23 +02:00
Copy Link

the detector is calling minetest.get_objects_inside_radius(pos, radius)

That will on C++ side walk through all active objects in memory (it will not load any blocks, so essentially only objects from those blocks that are currently loaded for other reasons.

And ... oh no, that is horrible ... every use of the detector (or when searching objects inside a radius anywhere, so maybe other code is affected as well), it walks through list of ALL server objects (and for each one checks radius and adds to output if radius is lower). Who invented this horrible *****?

looking at src/server/activeobjectmgr.cpp ...

getObjectsInsideRadius, getObjectsInArea, getAddedActiveObjectsAroundPos - all this walks through entire list, the objects are stored in std::unordered_map<u16, T *> m_active_objects

Once there is decent amount of players and some decent amount of active objects around them, this can slow down the server considerably.

the detector is calling minetest.get_objects_inside_radius(pos, radius) That will on C++ side walk through all active objects in memory (it will not load any blocks, so essentially only objects from those blocks that are currently loaded for other reasons. And ... oh no, that is horrible ... every use of the detector (or when searching objects inside a radius anywhere, so maybe other code is affected as well), it walks through list of ALL server objects (and for each one checks radius and adds to output if radius is lower). Who invented this horrible *****? looking at src/server/activeobjectmgr.cpp ... getObjectsInsideRadius, getObjectsInArea, getAddedActiveObjectsAroundPos - all this walks through entire list, the objects are stored in `std::unordered_map<u16, T *> m_active_objects` Once there is decent amount of players and some decent amount of active objects around them, this can slow down the server considerably.
sixer commented 2023-07-23 14:43:57 +02:00
Copy Link

active_block_range and active_object_send_range_blocks config values in minetest will influence how large is the area where server holds these active blocks and how many those objects could be.

`active_block_range` and `active_object_send_range_blocks` config values in minetest will influence how large is the area where server holds these active blocks and how many those objects could be.
whosit commented 2023-07-23 14:55:53 +02:00
Member
Copy Link

get_objects_inside_radius() has it's own issue, see #3723

`get_objects_inside_radius()` has it's own issue, see https://gitea.your-land.de/your-land/bugtracker/issues/3723
AliasAlreadyTaken commented 2023-07-23 16:03:27 +02:00
Owner
Copy Link

Both needs to be addressed: The get_objects_inside_radius in its own issue and this one will deal with limiting the entity detector to a reasonable range - even if it is not root cause of the lag we're hunting. What's a reasonable range? 4? 6? 8? What's the maximum a vacuum tube can grab from?

Both needs to be addressed: The get_objects_inside_radius in its own issue and this one will deal with limiting the entity detector to a reasonable range - even if it is not root cause of the lag we're hunting. What's a reasonable range? 4? 6? 8? What's the maximum a vacuum tube can grab from?
sixer commented 2023-07-23 16:42:19 +02:00
Copy Link

vacuum tube has max.8- but there may be other uses, object detector may be triggering something nearby at a small distance ... so I guess (max(active_block_range,active_object_send_range_blocks)+1) * 16 could be reasonable limit, as that distance would still somewhat reliably land into active blocks around player ... and anything beyond then relies on luck that the block of interest somehow happens to be loaded.

vacuum tube has max.8- but there may be other uses, object detector may be triggering something nearby at a small distance ... so I guess `(max(active_block_range,active_object_send_range_blocks)+1) * 16` could be reasonable limit, as that distance would still somewhat reliably land into active blocks around player ... and anything beyond then relies on luck that the block of interest somehow happens to be loaded.
whosit added the
1. kind/balancing
3. source/mod upstream
 labels 2023-07-23 17:10:21 +02:00
sixer commented 2023-07-23 19:24:50 +02:00
Copy Link

Also, the adjustable player detector can also have unlimited range - with few of them you can fairly accurately pinpoint anybody's position in the world from a distance :)

Also, the adjustable player detector can also have unlimited range - with few of them you can fairly accurately pinpoint anybody's position in the world from a distance :)
AliasAlreadyTaken commented 2023-07-23 20:22:50 +02:00
Owner
Copy Link

Then let's limit the player detector in range as well to the same maximum the entity detector will be.

Then let's limit the player detector in range as well to the same maximum the entity detector will be.
DragonWrangler commented 2023-07-23 20:32:07 +02:00
Copy Link

so far testing has shown that they aren't quite accurate. for example my entity detector in Rivendell was set to 5km, but only detected 1km or Glacierville now reading whosit's theory I will change the range of the detector to 300m so I don't overload the server

so far testing has shown that they aren't quite accurate. for example my entity detector in Rivendell was set to 5km, but only detected 1km or Glacierville now reading whosit's theory I will change the range of the detector to 300m so I don't overload the server
flux commented 2023-07-26 05:50:44 +02:00
Member
Copy Link

these need to have a max range of something like 16

these need to have a max range of something like 16
flux commented 2023-07-26 05:51:18 +02:00
Member
Copy Link

maybe if it's more than 8 nodes, they should detect mobs, but not accurately

maybe if it's more than 8 nodes, they should detect mobs, but not accurately
AzelfYL commented 2023-07-27 15:25:01 +02:00
Copy Link

Personally, I would suggest making the range large, but not very large - long distance entity detectors can be useful to players who want to build stuff like a large-scale perimeter warning system around their city. Personally, i suggest capping the detection range to 128 or 256 blocks.

Personally, I would suggest making the range large, but not very large - long distance entity detectors can be useful to players who want to build stuff like a large-scale perimeter warning system around their city. Personally, i suggest capping the detection range to 128 or 256 blocks.
whosit commented 2023-07-27 16:18:39 +02:00
Member
Copy Link

Having max range such that single player can have both entity and detector loaded at the same time makes sense.

But idealy some per-detector "budget" should be considered?
How much CPU time we are willing to give to one such detector?
How many objects can be processed in this time?
What is the expected radius that will contain this amount of objects?
(noting that this radius will be significantly smaller for a city with lots of signs and itemframes...)

This gives me another idea:
what if detector will dynamically adjust it's radius? If it got too many objects during previous scan -> reduce actual radius, then slowly increase it if we get less entities up to user-defined one. Kinda like "scanner ratelimiter". I'm sure everyone will love it XD

Having max range such that single player can have both entity and detector loaded at the same time makes sense. But idealy some per-detector "budget" should be considered? How much CPU time we are willing to give to one such detector? How many objects can be processed in this time? What is the expected radius that will contain this amount of objects? (noting that this radius will be significantly smaller for a city with lots of signs and itemframes...) This gives me another idea: what if detector will dynamically adjust it's radius? If it got too many objects during previous scan -> reduce actual radius, then slowly increase it if we get less entities up to user-defined one. Kinda like "scanner ratelimiter". I'm sure everyone will love it XD
😆 1
flux commented 2023-07-29 02:32:05 +02:00
Member
Copy Link

But idealy some per-detector "budget" should be considered?
How much CPU time we are willing to give to one such detector?
How many objects can be processed in this time?
What is the expected radius that will contain this amount of objects?
(noting that this radius will be significantly smaller for a city with lots of signs and itemframes...)

i do eventually want to get around to writing some general-purpose code scheduler for this game. i may get to that soon if i decide i need it for mob behavior.

> But idealy some per-detector "budget" should be considered? > How much CPU time we are willing to give to one such detector? > How many objects can be processed in this time? > What is the expected radius that will contain this amount of objects? > (noting that this radius will be significantly smaller for a city with lots of signs and itemframes...) i do eventually want to get around to writing some general-purpose code scheduler for this game. i may get to that soon if i decide i need it for mob behavior.
flux commented 2023-07-29 02:40:53 +02:00
Member
Copy Link

Personally, I would suggest making the range large, but not very large - long distance entity detectors can be useful to players who want to build stuff like a large-scale perimeter warning system around their city. Personally, i suggest capping the detection range to 128 or 256 blocks.

it certainly shouldn't extend beyond the active object range of a single player, so at most a max of somewhere around 100 depending on how that's measured

> Personally, I would suggest making the range large, but not very large - long distance entity detectors can be useful to players who want to build stuff like a large-scale perimeter warning system around their city. Personally, i suggest capping the detection range to 128 or 256 blocks. it certainly shouldn't extend beyond the active object range of a single player, so at most a max of somewhere around 100 depending on how that's measured
flux commented 2023-08-14 01:04:12 +02:00
Member
Copy Link

upstream issue: https://github.com/minetest-mods/MoreMesecons/issues/31

it shouldn't be hard to implement something but i'm exhausted rn.

upstream issue: https://github.com/minetest-mods/MoreMesecons/issues/31 it shouldn't be hard to implement something but i'm exhausted rn.
flux added the
4. step/blocked
 label 2023-08-14 21:28:07 +02:00
flux commented 2023-08-14 21:28:14 +02:00
Member
Copy Link

upstream PR https://github.com/minetest-mods/MoreMesecons/pull/32. then again my last PR to that mod got ignored.

upstream PR https://github.com/minetest-mods/MoreMesecons/pull/32. then again my last PR to that mod got ignored.
👍 1
flux added
4. step/ready to QA test
 and removed
4. step/blocked
 labels 2023-08-18 03:14:21 +02:00
flux commented 2023-08-18 03:15:16 +02:00
Member
Copy Link

upstream PR got accepted. the default maximum radius is 16, but can be overridden w/ the moremesecons_entity_detector.max_radius setting if need be.

upstream PR got accepted. the default maximum radius is 16, but can be overridden w/ the `moremesecons_entity_detector.max_radius` setting if need be.
👍 1
AliasAlreadyTaken added this to the 1.1.120 milestone 2023-08-18 12:55:57 +02:00
AliasAlreadyTaken commented 2023-08-25 08:39:18 +02:00
Owner
Copy Link

QA

Looks good, even existing ones won't use the "old" setting as far as I can tell.

QA Looks good, even existing ones won't use the "old" setting as far as I can tell.
AliasAlreadyTaken added the
4. step/QA OK
 label 2023-08-25 08:39:23 +02:00
flux added
5. result/fixed
 and removed
4. step/ready to QA test
 labels 2023-11-17 01:00:13 +01:00
AliasAlreadyTaken was unassigned by flux 2023-11-17 01:00:18 +01:00
flux commented 2023-11-17 01:00:49 +01:00
Member
Copy Link

this is live. my server-wide focus detector no longer works.

this is live. my server-wide focus detector no longer works.
flux closed this issue 2023-11-17 01:00:49 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
1. kind/balancing

Depends on balancing

  
1. kind/breaking

something that alters or disables an existing game mechanic

  
1. kind/bug

Something is not working

  
1. kind/construction

A build needs fixing

  
1. kind/documentation

Needs proper documentation

  
1. kind/enhancement

New feature

  
1. kind/griefing

players despoiling builds or nature

  
1. kind/invalid

Not a valid report, e.g. created by mistake with no content.

  
1. kind/meme

issue is mostly a joke

  
1. kind/node limit

something which works for or against the node limit

  
1. kind/other

Something not within the other kinds

  
1. kind/protocol

something concerning how staff should react to player requests, or how players should treat each other

  
2. prio/controversial

not likely to happen w/out a lot of discussion

  
2. prio/critical

Very important

  
2. prio/elevated

something players are eager to have fixed

  
2. prio/good first issue

the resolution to this is could be done by a new minetest contributor, who doesn't yet understand the mod ecosystem

  
2. prio/interesting

one of us has real interest in getting this implemented or fixed. however, more research might be needed.

  
2. prio/low

Not so important

  
3. source/art

art needs to be created or found for this to exist. includes sound, 3d modelling, and in-game building.

  
3. source/client

Issue is with the minetest client, or with player client configuration or the technical details of their setup

  
3. source/engine

Issue is due to a bug or feature of the minetest engine

  
3. source/ingame

Problem and solution exist in-game, e.g. builds or player moderation

  
3. source/integration

Two or more nonbuggy mechanics conflict, or our attempts to rectify conflicting mechanics have created a new bug

  
3. source/lag

A problem which is caused or made worse by lag, due to server processing issues, client processing issues, or network issues

  
3. source/license

A licensing problem is involved

  
3. source/mod upstream

Problem is upstream (not engine/client)

  
3. source/petz

yet another petz bugz.

  
3. source/testserver

Originates on the testserver, no effect on main yet

  
3. source/unknown

   
3. source/website

Affects the website

  
4. step/approved

Alias has approved this feature, someone should implement it

  
4. step/at work

Being worked on

  
4. step/blocked

we plan to do this, but other work has to be finished first

  
4. step/discussion

issue is under discussion, a solution has not been dictated or agreed upon

  
4. step/help wanted

Need some help

  
4. step/needs confirmation

   
4. step/partially fixed

this is mitigated or partially solved, but more work needs to be done

  
4. step/QA main

That's something we can only wait and see whether it hapens again: On the main server

  
4. step/QA NOK

Fix didn't yield the expected results

  
4. step/QA OK

tested

  
4. step/question

More information is needed

  
4. step/ready to deploy

has been QA tested by another person. has no outstanding issues. might be installed on prod, but needs final testing

  
4. step/ready to QA test

the code is supposedly fixed, but needs to be tested.

  
4. step/want approval

Someone can quickly implement this if Alias approves the change/feature

  
5. result/cannot reproduce

   
5. result/duplicate

This issue or pull request already exists

  
5. result/fixed

problem is fixed

  
5. result/maybe

not planned currently, but maybe some day

  
5. result/wontfix

the reported issue won't be changed, whether it's intentional or not.

No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/petz
3. source/testserver
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/QA main
4. step/QA NOK
4. step/QA OK
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
Milestone
Clear milestone
No items
No Milestone
1.1.120
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: your-land/bugtracker#4988
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?