/area_open should only work if the executor has control of the *master* area #6147

New Issue

Changed here:
169b039706
This broke translations for this command... I tried running mod_translation_updater.py, but it shuffled stuff too much, so decided to just ignore it for now...

Changed here: https://gitea.your-land.de/your-land/areas/commit/169b039706b882d7ea8ece2fc696bd430eeec545 This broke translations for this command... I tried running `mod_translation_updater.py`, but it shuffled stuff too much, so decided to just ignore it for now...

whosit added the

4. step/ready to QA test

label 2024-01-31 18:36:06 +00:00

AliasAlreadyTaken added this to the 1.1.123 milestone 2024-01-31 20:37:09 +00:00

AliasAlreadyTaken commented

2024-02-17 06:36:16 +00:00

QA

Works :)

QA Works :)

AliasAlreadyTaken added the

ugh/QA OK

label 2024-02-17 06:36:22 +00:00

flux commented

2024-02-18 05:54:21 +00:00

mod_translation_updater.py

i have no faith in that stuff. sounds like it doesn't have a defined sorting order and the result is sorted by python's hashing algorithm?

> `mod_translation_updater.py` i have no faith in that stuff. sounds like it doesn't have a defined sorting order and the result is sorted by python's hashing algorithm?

tour referenced this issue

2024-03-15 23:42:23 +00:00

Areas Rework #6497

whosit commented

2024-03-16 12:42:28 +00:00

Turns out this prevents city owners from creating open areas now.

😕 1

AliasAlreadyTaken modified the milestone from 1.1.123 to 1.1.124

2024-03-16 15:31:45 +00:00

AliasAlreadyTaken removed the

ugh/QA OK

label 2024-03-16 15:31:52 +00:00

Chache commented

2024-03-16 15:37:09 +00:00

Hi, as Whosit points out this has the unintended effect of no longer allowing city mayors to open areas inside their cities (so no public farms... etc.)

However, I've discovered this is only the case because when a new city is created, the City area is created first and then the mayor's area is created with /add_owner using the already existing City area.

I strongly recommend the order would be inverted. First, the mayor creates a master area to his/her name, then the account City is added (as a sub-area to the mayor's master area) via /add_owner command.

This would mean the mayor is still the owner of the higher master area and would allow them to open sub-areas within.

More importantly, this would make mayors spend 1 of their master areas for their city - because right now, that's not happening. My main area for Puerto del Sol (ID 4888) doesn't appear in my list of master areas (!) and it's so because it's a sub-area of the original City area. This is clearly not intended.

Just having mayors add a City sub-area to their main city area, then remove the original City area, would solve the 2 problems (opening of sub-areas + city areas not counting as a MA of their mayors) in one go and without having to change the code.

Hi, as Whosit points out this has the unintended effect of no longer allowing city mayors to open areas inside their cities (so no public farms... etc.) However, I've discovered this is only the case because when a new city is created, the City area is created first and then the mayor's area is created with /add_owner using the already existing City area. I strongly recommend the order would be inverted. First, the mayor creates a master area to his/her name, then the account City is added (as a sub-area to the mayor's master area) via /add_owner command. This would mean the mayor is still the owner of the higher master area and would allow them to open sub-areas within. More importantly, this would make mayors spend 1 of their master areas for their city - because right now, that's not happening. My main area for Puerto del Sol (ID 4888) doesn't appear in my list of master areas (!) and it's so because it's a sub-area of the original City area. This is clearly not intended. Just having mayors add a City sub-area to their main city area, then remove the original City area, would solve the 2 problems (opening of sub-areas + city areas not counting as a MA of their mayors) in one go and without having to change the code.

AliasAlreadyTaken commented

2024-03-16 15:39:15 +00:00

The city area needs to go on top. This was made so that a city exists and is protected even after a mayor accidentally deletes his master area.

With the cities update, we need to change a couple of things in areas anyways.

The city area needs to go on top. This was made so that a city exists and is protected even after a mayor accidentally deletes his master area. With the cities update, we need to change a couple of things in areas anyways.

Ravise commented

2024-03-17 11:06:40 +00:00

Can't the City area and the Mayor's area be two independent protections over the same land? That should give master ownership to both mayor and City.

AliasAlreadyTaken commented

2024-03-17 11:19:47 +00:00

Can't the City area and the Mayor's area be two independent protections over the same land? That should give master ownership to both mayor and City.

Interesting idea. It somehow conflicts with my desire to only have ONE master of an area, but it would technically achieve what is needed and the drawbacks are the same as in the current construction

> Can't the City area and the Mayor's area be two independent protections over the same land? That should give master ownership to both mayor and City. Interesting idea. It somehow conflicts with my desire to only have ONE master of an area, but it would technically achieve what is needed and the drawbacks are the same as in the current construction

tour commented

2024-03-17 12:29:52 +00:00

Can't the City area and the Mayor's area be two independent protections over the same land? That should give master ownership to both mayor and City.

Interesting idea. It somehow conflicts with my desire to only have ONE master of an area, but it would technically achieve what is needed and the drawbacks are the same as in the current construction

More than one masterarea will always cause trouble. There should be no trouble with additional fields in areas.areas[id]. Such as (for areas with the owner City)

mayors = {
	player1 = true,
    player2 = true
}

Let's assume you have the additional function getMasterareaID(id):

function canOpenArea(id, name)
	local master = getMasterareaID(id)
    return master.owner == name or (master.owner == "City" and master.mayors[name])
end

> > Can't the City area and the Mayor's area be two independent protections over the same land? That should give master ownership to both mayor and City. > > Interesting idea. It somehow conflicts with my desire to only have ONE master of an area, but it would technically achieve what is needed and the drawbacks are the same as in the current construction More than one masterarea will always cause trouble. There should be no trouble with additional fields in `areas.areas[id]`. Such as (for areas with the owner `City`) ```lua mayors = { player1 = true, player2 = true } ``` Let's assume you have the additional function `getMasterareaID(id)`: ```lua function canOpenArea(id, name) local master = getMasterareaID(id) return master.owner == name or (master.owner == "City" and master.mayors[name]) end ```

tour commented

2024-03-17 12:43:47 +00:00

Through that solution needs an update script:

for id, area in pairs(areas.areas) do
    if area.owner == "City" then
        area.mayors = {}
        local subareas = areas:getChildren(id)
        for _, sid in ipairs(subareas) do
            -- assume that every owner of a subarea from the cityarea is a mayor
            -- since such a subarea can only be created by staff so far
            -- most cities should only have one - the one of the official mayor
            area.mayors[areas.areas[sid].owner] = true
        end
    end
end

Through that solution needs an update script: ```lua for id, area in pairs(areas.areas) do if area.owner == "City" then area.mayors = {} local subareas = areas:getChildren(id) for _, sid in ipairs(subareas) do -- assume that every owner of a subarea from the cityarea is a mayor -- since such a subarea can only be created by staff so far -- most cities should only have one - the one of the official mayor area.mayors[areas.areas[sid].owner] = true end end end ```

flux commented

2024-03-18 02:34:00 +00:00

wait, the owner of the city is "City"? shouldn't that be a tag and not an owner?

tour commented

2024-03-18 10:25:49 +00:00

wait, the owner of the city is "City"? shouldn't that be a tag and not an owner?

Agree. But that's what I can see as a player. I don't know if there are is a better way to check for a city - I can only make suggestions based on the mt-mods areas code.

> wait, the owner of the city is "City"? shouldn't that be a tag and not an owner? Agree. But that's what I can see as a player. I don't know if there are is a better way to check for a city - I can only make suggestions based on the mt-mods areas code. ![image](/attachments/e470283d-bd61-4a29-99fa-dba4d6555d8d)

image.png

754 KiB

AliasAlreadyTaken commented

2024-03-18 14:49:15 +00:00

This is how we protect a city:

We create an area called "City", either manually or via /protect_city. Then we hand over the area to the City account. This area gets applied the yl_city attribute. Then we add the mayor as a subarea. The mayor can then add anyone to the subarea he wants to grant full control over the whole city, too.

Why do we need this City area at all? "City" is a service account. We're using this construction to protect a city serverside, so that not a mayor in a rage or during drama or even in an account loss situation can remove the masterarea and thus leave the city unprotected. It also gives us an immutable handle on the city - a mayor could anytime decide to change the name, with tricks even the area ID.

This is how we protect a city: We create an area called "City", either manually or via /protect_city. Then we hand over the area to the City account. This area gets applied the yl_city attribute. Then we add the mayor as a subarea. The mayor can then add anyone to the subarea he wants to grant full control over the whole city, too. Why do we need this City area at all? "City" is a service account. We're using this construction to protect a city serverside, so that not a mayor in a rage or during drama or even in an account loss situation can remove the masterarea and thus leave the city unprotected. It also gives us an immutable handle on the city - a mayor could anytime decide to change the name, with tricks even the area ID.

flux commented

2024-03-19 02:57:32 +00:00

i see. cities need to be "owned" by something other than the player who owns them, because they need to be conquerable by the voice. the player owner only has control so long as the voice hasn't conquered it - otherwise, they've got too much power over a conquered city.

this certainly complicates and negates my earlier analysis. i don't see an obvious optimal way of controlling /area_open (or /spawnit_area or similar) without explicit integration. perhaps we need to have a separate concept of a "master controller" of an area, instead of an owner?

but what if instead, when a city is conquered, the owner of the city changes from the founder, to "Voice" or something like that?

i see. cities need to be "owned" by something other than the player who owns them, because they need to be conquerable by the voice. the player owner only has control so long as the voice hasn't conquered it - otherwise, they've got too much power over a conquered city. this certainly complicates and negates my earlier analysis. i don't see an obvious optimal way of controlling `/area_open` (or `/spawnit_area` or similar) without explicit integration. perhaps we need to have a separate concept of a "master controller" of an area, instead of an owner? but what if instead, when a city is conquered, the owner of the city changes from the founder, to "Voice" or something like that?

AliasAlreadyTaken modified the milestone from 1.1.124 to Next

2024-04-22 12:30:41 +00:00

Sign in to join this conversation.