your-land/bugtracker
your-land
/
bugtracker
44
20
Code Issues 2.5k Projects 2 Wiki

Spawnit in a subarea ... #5784

New Issue
Closed
opened 2023-12-22 12:29:40 +00:00 by Boot · 7 comments
Boot commented 2023-12-22 12:29:40 +00:00
Member
Copy Link

Is it intended that a subtenant in an area can adjust the spawnit, in case of doubt against the will or in ignorance of the owner?

Is it intended that a subtenant in an area can adjust the spawnit, in case of doubt against the will or in ignorance of the owner?
AliasAlreadyTaken added the
4. step/question
1. kind/protocol
 labels 2023-12-22 17:43:48 +00:00
flux commented 2023-12-22 19:42:52 +00:00
Member
Copy Link

hm. i'm not sure whether there's a use case for such behavior.

currently, the owner of the master area can toggle spawnit off for the sub-area, though it sounds like that might not be good enough.

i could also make sure that the owner of a subarea can't enable spawnit unless they also own the master area.

hm. i'm not sure whether there's a use case for such behavior. currently, the owner of the master area can toggle spawnit off for the sub-area, though it sounds like that might not be good enough. i could also make sure that the owner of a subarea can't enable spawnit unless they also own the master area.
AliasAlreadyTaken commented 2023-12-22 20:01:21 +00:00
Owner
Copy Link

That's a general question. Should the master area have a say over what the subarea can or cannot do? In some contexts it makes sense, in some others it does not.

master over sub: City wants to to disallow nether portals and thus blacklists portalstones.
sub over master: City is protected, but wants to open an area for public farm

Same goes for spawnit: Should the "more specific" area take precedence or the one "closer to the owner" ?

That's a general question. Should the master area have a say over what the subarea can or cannot do? In some contexts it makes sense, in some others it does not. master over sub: City wants to to disallow nether portals and thus blacklists portalstones. sub over master: City is protected, but wants to open an area for public farm Same goes for spawnit: Should the "more specific" area take precedence or the one "closer to the owner" ?
flux commented 2023-12-22 20:09:41 +00:00
Member
Copy Link

fixed e2582d65db

if a sub-owner wants to enable spawnit in their subarea, they can always ask the master owner to toggle it.

fixed https://github.com/fluxionary/minetest-spawnit/commit/e2582d65dbb97cc6bc10e1926ad07664c71167e7 if a sub-owner wants to enable spawnit in their subarea, they can always ask the master owner to toggle it.
👍 2
flux added
4. step/ready to QA test
 and removed
4. step/question
 labels 2023-12-22 20:11:02 +00:00
Bla commented 2023-12-22 20:18:07 +00:00
Copy Link

Same goes for spawnit: Should the "more specific" area take precedence or the one "closer to the owner" ?

How many mob farms would you like in Haven? 😜

> Same goes for spawnit: Should the "more specific" area take precedence or the one "closer to the owner" ? How many mob farms would you like in Haven? 😜
flux commented 2023-12-22 20:33:09 +00:00
Member
Copy Link

for the record, i also feel like we should do this for "open" areas. there's no reason why a sub-owner should be able to make an area open without the master's permission.

for the record, i also feel like we should do this for "open" areas. there's no reason why a sub-owner should be able to make an area open without the master's permission.
👍 2
AliasAlreadyTaken was assigned by Boot 2024-01-15 21:03:12 +00:00
AliasAlreadyTaken added this to the 1.1.123 milestone 2024-02-26 13:34:16 +00:00
AliasAlreadyTaken commented 2024-02-28 23:37:43 +00:00
Owner
Copy Link

QA

As usual, this has uncertainties when there are by accident or construction more than one master area, but works in every sense that is sensible: OK

QA As usual, this has uncertainties when there are by accident or construction more than one master area, but works in every sense that is sensible: OK
AliasAlreadyTaken added the
ugh/QA OK
 label 2024-02-28 23:37:49 +00:00
flux added
5. result/fixed
 and removed
4. step/ready to QA test
 labels 2024-03-28 19:46:16 +00:00
AliasAlreadyTaken was unassigned by flux 2024-03-28 19:46:19 +00:00
flux commented 2024-03-28 19:46:27 +00:00
Member
Copy Link

live

live
flux closed this issue 2024-03-28 19:46:27 +00: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/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/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
Milestone
Clear milestone
No items
No Milestone
1.1.123
Projects
Clear projects
No project
Assignees
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#5784
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?