daydream reports: is it already suggested that a ... #3406
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/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
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#3406
Loading…
Reference in New Issue
Block a user
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?
daydream reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
so far as i know, no-one has requested that. i'm not sure why daydream is thinking about this, but i've got some experience w/ why this might be requested.
the naive reason is that if someone removes their area, anyone sharing that area should be de-listed as well. but there's a
/recursive_remove_areas
command, right? you'd assume that the "correct" thing would be to would be to inform people that it's their choice to remove all the sub areas or not, and that if they made the wrong choice, admins can fix it later.but that doesn't take into account how this "feature" can be exploited to smear other players. let me explain:
on blocky survival, i came across an area owned by a specific player who wasn't staff, but who i trusted a lot. the name of the area was something i won't repeat, but it was something you'd expect a nazi to promulgate. i banned the player. i paused a moment - this was someone i had trusted, and i wanted to be certain i was banning them properly. after searching through the server logs, i discovered that the player hadn't named the area themselves. the player hadn't even been aware the area existed. another player - an alt of a known troll - had protected an area, added another player to the area w/out that player's knowledge, named the area something really inappropriate, and then deleted their own area (not recursively), making it look like the area was named by my friend.
proposed solution: sub-areas should track who created them. if a player deletes an area, it should only delete the sub-areas they created themselves, or which were created by server staff. sub-areas should also track who originally created the area they belonged to - this can be used for debugging, but also will allow original owners to redefine their cities or other large areas.
I've suggested a history of areas (names, positions etc.) that is also visible to the player somewhere in the past. That might also help in this situation.
If there is no area, then there is also no history of an area which could be looked up. Ofc, we need to log it all, but a normal player doesn't have access to that.