Azelf reports: Discussion on the max limit of ... #5205
Labels
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/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/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
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#5205
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
Azelf reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
azelf felt that having a radius of 64 nodes would be better for creating automated defense systems. i don't disagree. we can change the value easily via
moremesecons_entity_detector.max_radius
setting.minetest.get_objects_inside_radius
needs to be made more efficient, but that's no reason to not extend the range a bit if it's actually useful. the current cost of that call is something like (#all_objects_on_server + 10 * #objects_inside_radius). for most calls, the total number of active objects on the server totally dominates the cost.I'd rather align that to the max range of existing, similar block like the player detector or the vacuum tube.
Among other things, I do not want long range radar towers detecting Voice attacks.
That's why I'd like to limit the range between 4 and 8.
4 is way to short, players will just place more of them.
8 might work but could be problematic for bigger things like automatic draw bridges.
I think 16 is a nice distance and also easy to visualize for players with displaying block bounds.
I agree with Bla
Perhaps long range detectors of Voice attacks could be helpful. Right now there has to be someone there in order for an attack to be successful (if the city isn't defended, Voices' troops would march in and despawn after conquering the city..). Those detectors don't have to be physical entities. Might just be a mob announcing that he saw something he/she/it was afraid of. Something like the reports from battles Kika sometimes delivers to us.
When a city employs sentries, they will announce appoaraching armies or whatever they think is noteworthy. That's a mecahnic of its own, part of the cities update
So basically they will act as the detectors for cities ?