sixer reports: when protecting area, you some ... #4145

New Issue

yourland-report · 2023-04-09T07:14:05Z

yourland-report commented

2023-04-09 07:14:05 +00:00

sixer reports a bug:

when protecting area, you sometimes get "Do not build here" warning. It would be nice if the warning showed how much closer (i.e. area is 148 close out of 150) it is in order for you to know how much you need to shrink your area to fit the limits

Player position:

{
	x = 2520.6179199219,
	z = 4494.4467773438,
	y = 2.5
}

Player look:

{
	x = -0.5031042098999,
	z = -0.86407333612442,
	y = 0.016230849549174
}

Player information:

{
	avg_jitter = 0.0010000001639128,
	connection_uptime = 1448,
	serialization_version = 29,
	patch = 1,
	formspec_version = 6,
	protocol_version = 41,
	state = "Active",
	minor = 6,
	max_rtt = 0.13899999856949,
	version_string = "5.6.1",
	major = 5,
	lang_code = "",
	ip_version = 6,
	min_rtt = 0.017000000923872,
	avg_rtt = 0.01799999922514,
	min_jitter = 0,
	max_jitter = 0.12099999934435
}

Player meta:

{
	fields = {
		inflicted_damage = "47194",
		jointime = "1678554780",
		bitten = "0",
		["stamina:poisoned"] = "no",
		repellant = "0",
		["ocean_build.last_warning"] = "1.68098e+09",
		["3d_armor_inventory"] = "return {\"3d_armor:boots_crystal 1 820\", \"3d_armor:chestplate_crystal 1 820\", \"3d_armor:helmet_crystal 1 820\", \"3d_armor:leggings_crystal 1 820\", \"shields:shield_rainbow 1 328\", \"\"}",
		xp = "26821",
		hud_state = "on",
		played_time = "144236",
		["stamina:level"] = "17",
		arenalib_infobox_arenaID = "0",
		["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}",
		digged_nodes = "28705",
		placed_nodes = "5910",
		died = "17",
		yl_commons_player_joined = "1681023007",
		["signslib:pos"] = "(2570,2,3151)",
		crafted = "760",
		yl_church = "return {[\"last_death\"] = {[\"z\"] = 2044, [\"x\"] = 871, [\"y\"] = -9649}, [\"last_death_portal\"] = 1680870047}",
		yl_commons_player_created = "1678554780",
		["ocean_build.ocean_built"] = "9",
		punch_count = "2695",
		["stamina:exhaustion"] = "25.5"
	}
}

Log identifier


[MOD] yl_report log identifier = Oll6gwEBDugZuDOsEN2c8iSrzM0qzR5F

Profiler save:

profile-20230409T071405.json_prettyEE

Status:

# Server: version: 5.6.1-yl | game: Minetest Game | uptime: 9d 3h 26min 6s | max lag: 1.13s | clients (22/52): AliasAlreadyTaken, Allan, answer2, Bailiff, bizon, Chache, copper248, daydream, Flippster, HorusDamocles, jaconer, labrat, niceride, Nickson_4, Papi, rewired_X, Service, sixer, Squawk, Stelio, Sysmatic, tomyoka

Teleport command:

/teleport xyz 2521 3 4494

Compass command:

/give_compass Construction Oll6gwEBDugZuDOsEN2c8iSrzM0qzR5F D2691E 2521 3 4494

sixer reports a bug: > when protecting area, you sometimes get "Do not build here" warning. It would be nice if the warning showed how much closer (i.e. area is 148 close out of 150) it is in order for you to know how much you need to shrink your area to fit the limits Player position: ``` { x = 2520.6179199219, z = 4494.4467773438, y = 2.5 } ``` Player look: ``` { x = -0.5031042098999, z = -0.86407333612442, y = 0.016230849549174 } ``` Player information: ``` { avg_jitter = 0.0010000001639128, connection_uptime = 1448, serialization_version = 29, patch = 1, formspec_version = 6, protocol_version = 41, state = "Active", minor = 6, max_rtt = 0.13899999856949, version_string = "5.6.1", major = 5, lang_code = "", ip_version = 6, min_rtt = 0.017000000923872, avg_rtt = 0.01799999922514, min_jitter = 0, max_jitter = 0.12099999934435 } ``` Player meta: ``` { fields = { inflicted_damage = "47194", jointime = "1678554780", bitten = "0", ["stamina:poisoned"] = "no", repellant = "0", ["ocean_build.last_warning"] = "1.68098e+09", ["3d_armor_inventory"] = "return {\"3d_armor:boots_crystal 1 820\", \"3d_armor:chestplate_crystal 1 820\", \"3d_armor:helmet_crystal 1 820\", \"3d_armor:leggings_crystal 1 820\", \"shields:shield_rainbow 1 328\", \"\"}", xp = "26821", hud_state = "on", played_time = "144236", ["stamina:level"] = "17", arenalib_infobox_arenaID = "0", ["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}", digged_nodes = "28705", placed_nodes = "5910", died = "17", yl_commons_player_joined = "1681023007", ["signslib:pos"] = "(2570,2,3151)", crafted = "760", yl_church = "return {[\"last_death\"] = {[\"z\"] = 2044, [\"x\"] = 871, [\"y\"] = -9649}, [\"last_death_portal\"] = 1680870047}", yl_commons_player_created = "1678554780", ["ocean_build.ocean_built"] = "9", punch_count = "2695", ["stamina:exhaustion"] = "25.5" } } ``` Log identifier ``` [MOD] yl_report log identifier = Oll6gwEBDugZuDOsEN2c8iSrzM0qzR5F ``` Profiler save: ``` profile-20230409T071405.json_prettyEE ``` Status: ``` # Server: version: 5.6.1-yl | game: Minetest Game | uptime: 9d 3h 26min 6s | max lag: 1.13s | clients (22/52): AliasAlreadyTaken, Allan, answer2, Bailiff, bizon, Chache, copper248, daydream, Flippster, HorusDamocles, jaconer, labrat, niceride, Nickson_4, Papi, rewired_X, Service, sixer, Squawk, Stelio, Sysmatic, tomyoka ``` Teleport command: ``` /teleport xyz 2521 3 4494 ``` Compass command: ``` /give_compass Construction Oll6gwEBDugZuDOsEN2c8iSrzM0qzR5F D2691E 2521 3 4494 ```

👍 3

AliasAlreadyTaken was assigned by yourland-report

2023-04-09 07:14:05 +00:00

AliasAlreadyTaken added the

1. kind/enhancement

label 2023-04-09 15:28:18 +00:00

sixer commented

2023-04-18 07:26:26 +00:00

This could be fixed by improving the logic to have more informative messages when protecting - at least stating distance of the other area and direction to it

I can fix the code and send PR to print more informative message and possibly also add another command that would just check the status on nearby areas (based on area_pos1, area_pos2) without protecting an area - to avoid loop of protecting area, removing area, adjusting coords and trying again.

Is the code to be fixed in a publicly-available code (areas), or is it specific to your-land? I'd be guessing yl_areas ....

This could be fixed by improving the logic to have more informative messages when protecting - at least stating distance of the other area and direction to it I can fix the code and send PR to print more informative message and possibly also add another command that would just check the status on nearby areas (based on area_pos1, area_pos2) without protecting an area - to avoid loop of protecting area, removing area, adjusting coords and trying again. Is the code to be fixed in a publicly-available code (areas), or is it specific to your-land? I'd be guessing yl_areas ....

flux commented

2023-04-18 22:16:24 +00:00

Is the code to be fixed in a publicly-available code (areas), or is it specific to your-land? I'd be guessing yl_areas ....

yeah i think it's part of yl_areas_addons, if you want to submit a PR, i think alias would probably happily give you access.

> Is the code to be fixed in a publicly-available code (areas), or is it specific to your-land? I'd be guessing yl_areas .... yeah i think it's part of yl_areas_addons, if you want to submit a PR, i think alias would probably happily give you access.

👍 1

AliasAlreadyTaken commented

2023-04-19 00:51:18 +00:00

There are plans to change the distance code to opt-in. During this change we need to add a couple of other changes as well.

yl_areas_addons does not contain secrets, so we could have anyone take a look and help improve it.

@sixer : If you want, I'll write up the changes I'd like to be done, so you or any volunteer could give it a try? No need to implement them all, but when one is already over one change, might be a god idea to add the others, too.

There are plans to change the distance code to opt-in. During this change we need to add a couple of other changes as well. yl_areas_addons does not contain secrets, so we could have anyone take a look and help improve it. @sixer : If you want, I'll write up the changes I'd like to be done, so you or any volunteer could give it a try? No need to implement them all, but when one is already over one change, might be a god idea to add the others, too.

AliasAlreadyTaken added the

2. prio/good first issue

label 2023-04-19 00:51:24 +00:00

sixer commented

2023-04-20 18:46:05 +00:00

If the addon source would be available to me (or available in general, not sure how much you wish to open it), I can try to add some other changes along as well ....

AliasAlreadyTaken commented

2023-04-20 20:50:23 +00:00

yl_areas_addons is meant to be made available anyways and doesn't contain any secrets. If you wish to try your hand, I'll add you to the repo and write some spec :)

sixer commented

2023-05-08 14:05:58 +00:00

Ok, I might take a look at the code.

I think it would be usable also to add some command that merely checks for nearby areas within some distance (like 450? 300 city limit + 150 your limit for expansion), which would give output like:

Area Name1 of Player A is 230 nodes to north (ok).
Area Name2 of Player B is 248 nodes to south (ok).
City area XYZ is 289 nodes to west (collision).

This command would make it easier to find a suitable area (in the example above you immediately see that moving 13 nodes to east and extending area eastward from there would likely get you a usable spot) instead of trying to protect something, fail, iterate with moving or making smaller area and in the end finding that you do not have enough space to expand in the future.

(I can add that once I'll be modifying the code)

Ok, I might take a look at the code. I think it would be usable also to add some command that merely checks for nearby areas within some distance (like 450? 300 city limit + 150 your limit for expansion), which would give output like: Area Name1 of Player A is 230 nodes to north (ok). Area Name2 of Player B is 248 nodes to south (ok). City area XYZ is 289 nodes to west (collision). This command would make it easier to find a suitable area (in the example above you immediately see that moving 13 nodes to east and extending area eastward from there would likely get you a usable spot) instead of trying to protect something, fail, iterate with moving or making smaller area and in the end finding that you do not have enough space to expand in the future. (I can add that once I'll be modifying the code)

AliasAlreadyTaken commented

2023-05-09 03:13:16 +00:00

Area detectors: Rather no. It is already simple enough to find quest areas that are meant to stay hidden.

Here is a related issue: #4331

Since both have some discussion, they need to be kept open until the feature is OK

If you want to implement, here's a basic spec:

Make a staff command to display which area in what direction you intersect.
Create a chatcommand /area_distance AREAID DISTANCE, which takes two parameters: the first is a valid areaid owned by the sender of the command and which is a masterarea, the second is a distance between 0 and 150 for normal areas and between 0 and 300 for city areas. No negative, only integers.
The area_distance command causes the area with AREAID gain a attribute: key is yl_distance and value is DISTANCE. Previously saved values are written over. The event is logged. The event is output to the user with area id, new and old value.
If this attribute is not present, it is assumed to be the maximum value: 150 for normal areas and 300 for cities, factions and questareas.
When a new masterarea is created, it must be checked, whether there is an area closer than the minimum allowed distance. This counts from area border to area border. If the action is disallowed, send in yellow the area ID, area name and area owner but not the exact location or distance of the private area that caused the veto and in orange if a city, faction or questarea. Log the full event.
Add a callback that is executed when such an area is created, another when an areacreation is denied
Bonus: Make it that when a masterarea is created entirely within another masterarea, it does not coujnt against the area maximum and the larger masterarea become the parent area. Be careful when this action is ambiguous, there may be cases when there are two or more master areas in one place. Log the event fully.
Bonus: Create a function that can find all masterareas that are entirely inside the borders of a larger masterarea and display them in the log.
If a user with the areas priv executes any of those forbidden actions, the action must be carried out, but the person who sent the command must be notified.

Please notify me if anyone would like to pick this up, I#ll give you access to the relevant repo.

Area detectors: Rather no. It is already simple enough to find quest areas that are meant to stay hidden. Here is a related issue: #4331 Since both have some discussion, they need to be kept open until the feature is OK If you want to implement, here's a basic spec: * [ ] Make a staff command to display which area in what direction you intersect. * [ ] Create a chatcommand /area_distance AREAID DISTANCE, which takes two parameters: the first is a valid areaid owned by the sender of the command and which is a masterarea, the second is a distance between 0 and 150 for normal areas and between 0 and 300 for city areas. No negative, only integers. * [ ] The area_distance command causes the area with AREAID gain a attribute: key is yl_distance and value is DISTANCE. Previously saved values are written over. The event is logged. The event is output to the user with area id, new and old value. * [ ] If this attribute is not present, it is assumed to be the maximum value: 150 for normal areas and 300 for cities, factions and questareas. * [ ] When a new masterarea is created, it must be checked, whether there is an area closer than the minimum allowed distance. This counts from area border to area border. If the action is disallowed, send in yellow the area ID, area name and area owner but not the exact location or distance of the private area that caused the veto and in orange if a city, faction or questarea. Log the full event. * [ ] Add a callback that is executed when such an area is created, another when an areacreation is denied * [ ] Bonus: Make it that when a masterarea is created entirely within another masterarea, it does not coujnt against the area maximum and the larger masterarea become the parent area. Be careful when this action is ambiguous, there may be cases when there are two or more master areas in one place. Log the event fully. * [ ] Bonus: Create a function that can find all masterareas that are entirely inside the borders of a larger masterarea and display them in the log. * [ ] If a user with the areas priv executes any of those forbidden actions, the action must be carried out, but the person who sent the command must be notified. Please notify me if anyone would like to pick this up, I#ll give you access to the relevant repo.

AliasAlreadyTaken added the

4. step/approved

label 2023-05-09 03:17:01 +00:00

sixer commented

2023-05-09 04:03:55 +00:00

The area detectors could then exclude quest areas from their output.

Currently, if you do /protect_this close to quest area, you get message "Do NOT build here, unless invited by Quest" ... which gives away its presence. Also, it seems that now the distance is 150 for quest areas (or at lest for the one near my base), is that supposed to raise to 300? That would make its detection this way easier, when it is about 100 nodes away, you often see it on the map and with your own eyes anyway, unless hidden somehow.

not the exact location or distance of the private area that caused the veto

Not giving at least some hint where to move will make creation of new areas in any somewhat crowded area a nightmare. Imagine a newbie landing via catapult somewhere, trying to protect area, finding that it intersects something. He would have no idea if he has just to shift borders a bit, or if the area is just right next to him. He would also have no idea in which direction to go to get away from that area to get far enough.

There is also question how this should work for areas that currently violate those condition, but there may be some agreement between the owners.

For this, non-uniform distance may be useful, something like "50 to the north, 150 in other directions" (internally stored as 4 numbers)

area closer than the minimum allowed distance. This counts from area border to area border.

If the areas are separated with 120 distance in X and 130 distance in Z, should euclidean distance be used (which would be 176), or min-distance be used (which would be 120)?

The area detectors could then exclude quest areas from their output. Currently, if you do /protect_this close to quest area, you get message "Do NOT build here, unless invited by Quest" ... which gives away its presence. Also, it seems that now the distance is 150 for quest areas (or at lest for the one near my base), is that supposed to raise to 300? That would make its detection this way easier, when it is about 100 nodes away, you often see it on the map and with your own eyes anyway, unless hidden somehow. > not the exact location or distance of the private area that caused the veto Not giving at least some hint where to move will make creation of new areas in any somewhat crowded area a nightmare. Imagine a newbie landing via catapult somewhere, trying to protect area, finding that it intersects something. He would have no idea if he has just to shift borders a bit, or if the area is just right next to him. He would also have no idea in which direction to go to get away from that area to get far enough. There is also question how this should work for areas that currently violate those condition, but there may be some agreement between the owners. For this, non-uniform distance may be useful, something like "50 to the north, 150 in other directions" (internally stored as 4 numbers) > area closer than the minimum allowed distance. This counts from area border to area border. If the areas are separated with 120 distance in X and 130 distance in Z, should euclidean distance be used (which would be 176), or min-distance be used (which would be 120)?

sixer commented

2023-05-09 07:05:03 +00:00

Recently I encountered another issue that could be avoided if there was possibility to detect protected areas from a distance - I starter building a tunnel to connect two points, but after about 500 meters I encountered an unexpected protected area.

I guess somebody built an underground base or reserved space for expanding? That area was not apparent when examining the planned tunnel path from the surface.

Now I'll have to try to find some way around, but part of the tunnel is wasted effort and without visibility of the areas (land register shows size only of the one right next to me) I do not know if there are any more areas that may block me, or in which direction to try the detour.

Recently I encountered another issue that could be avoided if there was possibility to detect protected areas from a distance - I starter building a tunnel to connect two points, but after about 500 meters I encountered an unexpected protected area. I guess somebody built an underground base or reserved space for expanding? That area was not apparent when examining the planned tunnel path from the surface. Now I'll have to try to find some way around, but part of the tunnel is wasted effort and without visibility of the areas (land register shows size only of the one right next to me) I do not know if there are any more areas that may block me, or in which direction to try the detour.

AliasAlreadyTaken commented

2023-05-09 07:05:31 +00:00

The area detectors could then exclude quest areas from their output.

Not only Quest has good cause for privacy and non-detection.

Currently, if you do /protect_this close to quest area, you get message "Do NOT build here, unless invited by Quest" ... which gives away its presence.

Yes, that's unfortunate, but I can't tell people to go away, after they were not informed that there's a questarea nearby.

Also, it seems that now the distance is 150 for quest areas (or at lest for the one near my base), is that supposed to raise to 300? That would make its detection this way easier, when it is about 100 nodes away, you often see it on the map and with your own eyes anyway, unless hidden somehow.

If it is "somewhere in 300 distance", it is much harder to determine where exactly.

Not giving at least some hint where to move will make creation of new areas in any somewhat crowded area a nightmare.

This makes a good PRO case. If wedging in into an already crowded area is hard, then we achieved our goal. Move elsewhere.

Imagine a newbie landing via catapult somewhere, trying to protect area, finding that it intersects something. He would have no idea if he has just to shift borders a bit, or if the area is just right next to him. He would also have no idea in which direction to go to get away from that area to get far enough.

Yes. If it doesn't work on multiple occasions, then this means the area is crowded and he must move away. Like ... far away.

There is also question how this should work for areas that currently violate those condition, but there may be some agreement between the owners.

If there is a way to detect those constellations, all the better.

For this, non-uniform distance may be useful, something like "50 to the north, 150 in other directions" (internally stored as 4 numbers)

Sounds interesting, but it's much harder to understand than a uniform distance. I already wonder how to tell people to "temporarily lower the distance if they want their friend settle nearby". I'd rather stay with one distance.

If the areas are separated with 120 distance in X and 130 distance in Z, should euclidean distance be used (which would be 176), or min-distance be used (which would be 120)?

You mean in the staff command? Could be both, it's more informational, most staff can teleport to an area to see where it's actually located, if need be. Staff is not meant to be a handy area detector, only when it becomes apparent there may be something wrong.

> The area detectors could then exclude quest areas from their output. Not only Quest has good cause for privacy and non-detection. > Currently, if you do /protect_this close to quest area, you get message "Do NOT build here, unless invited by Quest" ... which gives away its presence. Yes, that's unfortunate, but I can't tell people to go away, after they were not informed that there's a questarea nearby. > Also, it seems that now the distance is 150 for quest areas (or at lest for the one near my base), is that supposed to raise to 300? That would make its detection this way easier, when it is about 100 nodes away, you often see it on the map and with your own eyes anyway, unless hidden somehow. If it is "somewhere in 300 distance", it is much harder to determine where exactly. > Not giving at least some hint where to move will make creation of new areas in any somewhat crowded area a nightmare. This makes a good PRO case. If wedging in into an already crowded area is hard, then we achieved our goal. Move elsewhere. > Imagine a newbie landing via catapult somewhere, trying to protect area, finding that it intersects something. He would have no idea if he has just to shift borders a bit, or if the area is just right next to him. He would also have no idea in which direction to go to get away from that area to get far enough. Yes. If it doesn't work on multiple occasions, then this means the area is crowded and he must move away. Like ... far away. > There is also question how this should work for areas that currently violate those condition, but there may be some agreement between the owners. If there is a way to detect those constellations, all the better. > For this, non-uniform distance may be useful, something like "50 to the north, 150 in other directions" (internally stored as 4 numbers) Sounds interesting, but it's much harder to understand than a uniform distance. I already wonder how to tell people to "temporarily lower the distance if they want their friend settle nearby". I'd rather stay with one distance. > If the areas are separated with 120 distance in X and 130 distance in Z, should euclidean distance be used (which would be 176), or min-distance be used (which would be 120)? You mean in the staff command? Could be both, it's more informational, most staff can teleport to an area to see where it's actually located, if need be. Staff is not meant to be a handy area detector, only when it becomes apparent there may be something wrong.

sixer commented

2023-05-09 08:38:04 +00:00

The area detectors could then exclude quest areas from their output.

Not only Quest has good cause for privacy and non-detection.

At that point the existence of area is no longer a secret. For privacy, use locked doors or walls or fences. In open land, anybody can walk over open parts of your property.

Detecting may actually help with privacy, as you often want to avoid others, so if you detect somebody in planned path/spot, you move away. Without detection, you usually detect them by suddenly ending at edge of their property with your road (oh ... this block is protected ... )

Detectors can also help with case where you want more room. You may be able by luck/unluck to get a nice area without anybody nearby on first attempt (yay! I'll build here) .. just to realize later there are people 152 nodes away and you have minimal place to expand.

Currently, if you do /protect_this close to quest area, you get message "Do NOT build here, unless invited by Quest" ... which gives away its presence.

Yes, that's unfortunate, but I can't tell people to go away, after they were not informed that there's a questarea nearby.

Also, it seems that now the distance is 150 for quest areas (or at lest for the one near my base), is that supposed to raise to 300? That would make its detection this way easier, when it is about 100 nodes away, you often see it on the map and with your own eyes anyway, unless hidden somehow.

If it is "somewhere in 300 distance", it is much harder to determine where exactly.

Not really ... go in random direction and retry detection every 30 nodes or so. Once you stop detecting it, it is 300 nodes behind your back. Or if you suddenly get different message (about intersecting protection with the area) ... you found it.

But even without this, once you know something is 300 nodes from you and not elsewhere on 64Kx64K plane, with crystal boots and sprinting you scout the nearby area fairly fast to find it.

So it may be slightly harder to pinpoint its exact location, but you are able to detect its vicinity from double the distance. As a result, definitely easier to find one, not harder.

Not giving at least some hint where to move will make creation of new areas in any somewhat crowded area a nightmare.

This makes a good PRO case. If wedging in into an already crowded area is hard, then we achieved our goal. Move elsewhere.

Imagine a newbie landing via catapult somewhere, trying to protect area, finding that it intersects something. He would have no idea if he has just to shift borders a bit, or if the area is just right next to him. He would also have no idea in which direction to go to get away from that area to get far enough.

Yes. If it doesn't work on multiple occasions, then this means the area is crowded and he must move away. Like ... far away.

For newbies, that "far away" may be often another server :)
Newbies do not have crystal boots and walk slowly and free usable spots near ship or airship destinations are no more ... so unless there would be well visible option for newbies to catapult to a truly random place anywhere in map (and therefore minimal chance of landing near somebody else's property), this rule will cause them headache.

There is also question how this should work for areas that currently violate those condition, but there may be some agreement between the owners.

If there is a way to detect those constellations, all the better.

Could be doable by script parsing and analyzing current file with areas.
But there is no way to auto-detect any existing agreements. They could be via chat, internal mail, discord, or e-mail or other kind of private communication not visible to the server ...

For this, non-uniform distance may be useful, something like "50 to the north, 150 in other directions" (internally stored as 4 numbers)

Sounds interesting, but it's much harder to understand than a uniform distance. I already wonder how to tell people to "temporarily lower the distance if they want their friend settle nearby". I'd rather stay with one distance.

There could be use-case to add people to the exclusion list for this distance, i.e. friend X can ignore my distance rules (so I don't have to fiddle with distances in my area again if he wants to expand), for others I have lowered it to 120.

If the areas are separated with 120 distance in X and 130 distance in Z, should euclidean distance be used (which would be 176), or min-distance be used (which would be 120)?

You mean in the staff command? Could be both, it's more informational, most staff can teleport to an area to see where it's actually located, if need be. Staff is not meant to be a handy area detector, only when it becomes apparent there may be something wrong.

I mean for all distance measurements.

> > The area detectors could then exclude quest areas from their output. > > Not only Quest has good cause for privacy and non-detection. At that point the existence of area is no longer a secret. For privacy, use locked doors or walls or fences. In open land, anybody can walk over open parts of your property. Detecting may actually help with privacy, as you often want to avoid others, so if you detect somebody in planned path/spot, you move away. Without detection, you usually detect them by suddenly ending at edge of their property with your road (oh ... this block is protected ... ) Detectors can also help with case where you want more room. You may be able by luck/unluck to get a nice area without anybody nearby on first attempt (yay! I'll build here) .. just to realize later there are people 152 nodes away and you have minimal place to expand. > > Currently, if you do /protect_this close to quest area, you get message "Do NOT build here, unless invited by Quest" ... which gives away its presence. > > Yes, that's unfortunate, but I can't tell people to go away, after they were not informed that there's a questarea nearby. > > > Also, it seems that now the distance is 150 for quest areas (or at lest for the one near my base), is that supposed to raise to 300? That would make its detection this way easier, when it is about 100 nodes away, you often see it on the map and with your own eyes anyway, unless hidden somehow. > > If it is "somewhere in 300 distance", it is much harder to determine where exactly. Not really ... go in random direction and retry detection every 30 nodes or so. Once you stop detecting it, it is 300 nodes behind your back. Or if you suddenly get different message (about intersecting protection with the area) ... you found it. But even without this, once you know something is 300 nodes from you and not elsewhere on 64Kx64K plane, with crystal boots and sprinting you scout the nearby area fairly fast to find it. So it may be slightly harder to pinpoint its exact location, but you are able to detect its vicinity from double the distance. As a result, definitely easier to find one, not harder. > > > Not giving at least some hint where to move will make creation of new areas in any somewhat crowded area a nightmare. > > This makes a good PRO case. If wedging in into an already crowded area is hard, then we achieved our goal. Move elsewhere. > > > Imagine a newbie landing via catapult somewhere, trying to protect area, finding that it intersects something. He would have no idea if he has just to shift borders a bit, or if the area is just right next to him. He would also have no idea in which direction to go to get away from that area to get far enough. > > Yes. If it doesn't work on multiple occasions, then this means the area is crowded and he must move away. Like ... far away. For newbies, that "far away" may be often another server :) Newbies do not have crystal boots and walk slowly and free usable spots near ship or airship destinations are no more ... so unless there would be well visible option for newbies to catapult to a truly random place anywhere in map (and therefore minimal chance of landing near somebody else's property), this rule will cause them headache. > > There is also question how this should work for areas that currently violate those condition, but there may be some agreement between the owners. > > If there is a way to detect those constellations, all the better. Could be doable by script parsing and analyzing current file with areas. But there is no way to auto-detect any existing agreements. They could be via chat, internal mail, discord, or e-mail or other kind of private communication not visible to the server ... > > For this, non-uniform distance may be useful, something like "50 to the north, 150 in other directions" (internally stored as 4 numbers) > > Sounds interesting, but it's much harder to understand than a uniform distance. I already wonder how to tell people to "temporarily lower the distance if they want their friend settle nearby". I'd rather stay with one distance. There could be use-case to add people to the exclusion list for this distance, i.e. friend X can ignore my distance rules (so I don't have to fiddle with distances in my area again if he wants to expand), for others I have lowered it to 120. > > If the areas are separated with 120 distance in X and 130 distance in Z, should euclidean distance be used (which would be 176), or min-distance be used (which would be 120)? > > You mean in the staff command? Could be both, it's more informational, most staff can teleport to an area to see where it's actually located, if need be. Staff is not meant to be a handy area detector, only when it becomes apparent there may be something wrong. I mean for all distance measurements.

sixer commented

2023-05-09 23:52:01 +00:00

I thought of another type of privacy-preserving area detector, when you run the command it would:

check if there are no areas within the limits (32+150 for normal areas, 32+300 for special ones) - with 32 being half of area size, assuming area that would be available by "protect_this"
- If no, check for limits increased by 80 and based on second check:
- - If extended radius is free of areas: "This place is safe to settle and provides space for future expansion".
- - If extended radius is not free of areas: "This place is safe to settle, but some neighboring areas may limit future expansion".
if current place is unsuitable due to conflicts, it will try to find a free space within 500 nodes that could hold 64x64 area while satisfying the rules, preferring to find rather a closer area than a distant one. Based on result of this search, output one of:
- There is no suitable area to settle within 500 nodes.
- This area is unsuitable, but a suitable area can be found 215 nodes to north and 124 nodes to east. (or possibly also outputting absolute coordinates)

When locating free space, perform some sanity check of area fitness - the middle and at least one of the corners must not be water (64x64 sea area is unsuitable for building a base)

The values 80 and 500 could be replaced with different fitting values, those are only suggested defaults by me.

Such command would help with finding a suitable area significantly, while not revealing any information about any neighboring areas.

What do you think of such command?

I thought of another type of privacy-preserving area detector, when you run the command it would: * check if there are no areas within the limits (32+150 for normal areas, 32+300 for special ones) - with 32 being half of area size, assuming area that would be available by "protect_this" * * If no, check for limits increased by 80 and based on second check: * * * If extended radius is free of areas: "This place is safe to settle and provides space for future expansion". * * * If extended radius is not free of areas: "This place is safe to settle, but some neighboring areas may limit future expansion". * if current place is unsuitable due to conflicts, it will try to find a free space within 500 nodes that could hold 64x64 area while satisfying the rules, preferring to find rather a closer area than a distant one. Based on result of this search, output one of: * * There is no suitable area to settle within 500 nodes. * * This area is unsuitable, but a suitable area can be found 215 nodes to north and 124 nodes to east. (or possibly also outputting absolute coordinates) When locating free space, perform some sanity check of area fitness - the middle and at least one of the corners must not be water (64x64 sea area is unsuitable for building a base) The values 80 and 500 could be replaced with different fitting values, those are only suggested defaults by me. Such command would help with finding a suitable area significantly, while not revealing any information about any neighboring areas. What do you think of such command?

AliasAlreadyTaken added this to the Alias@work project 2023-05-10 05:24:55 +00:00

AliasAlreadyTaken removed this from the Alias@work project 2024-03-13 14:28:10 +00:00

tour referenced this issue

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

Areas Rework #6497

Sign in to join this conversation.