AliasAlreadyTaken reports: area in nether ...
#3870
Closed
opened 3 months ago by yourland-report
·
11 comments
Labels
Clear labels
Depends on balancing
something that alters or disables an existing game mechanic
Something is not working
A build needs fixing
Needs proper documentation
New feature
players despoiling builds or nature
Not a valid report, e.g. created by mistake with no content.
issue is mostly a joke
something which works for or against the node limit
Something not within the other kinds
something concerning how staff should react to player requests, or how players should treat each other
not likely to happen w/out a lot of discussion
Very important
something players are eager to have fixed
the resolution to this is could be done by a new minetest contributor, who doesn't yet understand the mod ecosystem
one of us has real interest in getting this implemented or fixed. however, more research might be needed.
Not so important
art needs to be created or found for this to exist. includes sound, 3d modelling, and in-game building.
Issue is with the minetest client, or with player client configuration or the technical details of their setup
Issue is due to a bug or feature of the minetest engine
Problem and solution exist in-game, e.g. builds or player moderation
Two or more nonbuggy mechanics conflict
A problem which is caused or made worse by lag, due to server processing issues, client processing issues, or network issues
Problem is upstream (not engine/client)
Affects the website
Alias has approved this feature, someone should implement it
Being worked on
we plan to do this, but other work has to be finished first
issue is under discussion, a solution has not been dictated or agreed upon
Need some help
this is mitigated or partially solved, but more work needs to be done
More information is needed
has been QA tested by another person. has no outstanding issues. might be installed on prod, but needs final testing
the code is supposedly fixed, but needs to be tested.
Someone can quickly implement this if Alias approves the change/feature
This issue or pull request already exists
problem is fixed
not planned currently, but maybe some day
the reported issue won't be changed, whether it's intentional or not.
yet another petz bugz.
That's something we can only wait and see whether it hapens again: On the main server
Fix didn't yield the expected results
tested
Apply 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
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/mod upstream
Problem is upstream (not engine/client)
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/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.
ugh/petz
yet another petz bugz.
ugh/QA main
That's something we can only wait and see whether it hapens again: On the main server
ugh/QA NOK
Fix didn't yield the expected results
ugh/QA OK
tested
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/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
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Set Project
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
4 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#3870
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
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