AliasAlreadyTaken reports: area in nether ... #3870
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#3870
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?
AliasAlreadyTaken reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
Somehow the user yoneda managed to create an area in the nether.
There are no peculiar actions before or after. As planned, an explosion occurred at the position of the person who issued the command:
Why did that happen twice??
still reviewing, but i see this logic:
bc9e732832/chatcommand_protect_this.lua (L56-L62)
where are the consequences for creating areas in the nether defined?
so, it looks like,
areas.registered_on_adds
is invoked after the area is created. i'm actually not sure how it prevents normal areas from being created. in any event, we're not using the API properly. for one, we don't override canProtectArea or (whatever API action is appropriate). i'll take a look at this tomorrow, marking as high priority.Actually we do overwrite areas:registerOnAdd
https://gitea.your-land.de/your-land/yl_nether/src/branch/yl_stable/compat/areas.lua#L9
That's where we remove the area in the next step if it was created in the nether ... ???
that's not an override of that function, that's a call to that function, which adds the defined callback, which is triggered after the area is created.
actually, the old behavior of the callback was almost right, but there's a race condition on removing the "invalid" area, and in some cases the removal won't get registered. i've written some code to avoid that by preventing the creation of the area in the first place:
da0808c0c4
That's how we can test whether it worked:
currently, staff can protect areas in the nether, so make sure to test w/ a non-staff account.
Those commands are meant to create a giant area over all the nether, then test whether there's an area inside or intersects with and area someone else might have created ;)
Ofc after a clandestine check I'll immediately remove the area again.
Else I'd have to go through the areas.areas and check myself
You could also use areas:getAreasIntersectingArea(pos1, pos2) directly and skip creating+deleting an area
this is live