JeCel reports: Long Area lists (bottom left c ... #1794

New Issue

yourland-report · 2022-04-18T23:46:09Z

yourland-report commented

2022-04-18 23:46:09 +00:00

JeCel reports a bug:

Long Area lists (bottom left corner) are very disturbing. Would it be possible to implement a feature that let's you minimize that list?

Player position:

{
	y = 3.5,
	x = 845.21105957031,
	z = 1976.5189208984
}

Player look:

{
	y = -0.057564023882151,
	x = -0.99549227952957,
	z = 0.075375534594059
}

Player information:

{
	min_rtt = 0.021999999880791,
	max_rtt = 0.53100001811981,
	connection_uptime = 12732,
	max_jitter = 0.48800000548363,
	minor = 4,
	major = 5,
	ip_version = 6,
	formspec_version = 4,
	patch = 1,
	protocol_version = 39,
	serialization_version = 28,
	lang_code = "",
	version_string = "5.4.1",
	avg_rtt = 0.027000000700355,
	state = "Active",
	avg_jitter = 0.0010000001639128,
	min_jitter = 0
}

Player meta:

{
	fields = {
		["3d_armor_inventory"] = "return {\"3d_armor:helmet_crystal 1 22300\", \"3d_armor:chestplate_crystal 1 22420\", \"3d_armor:leggings_crystal 1 22300\", \"shields:shield_crystal 1 22300\", \"3d_armor:boots_crystal 1 26260\", \"\"}",
		yl_commons_thankyou = "4",
		jointime = "1621787993",
		yl_commons_player_joined = "1650312870",
		["stamina:exhaustion"] = "9",
		digged_nodes = "356507",
		bitten = "0",
		["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}",
		partychat = "party",
		yl_church = "return {[\"last_death\"] = {[\"y\"] = 16, [\"x\"] = 6198, [\"z\"] = 10043}}",
		played_time = "739307",
		["stamina:level"] = "18",
		xp = "562496",
		arenalib_infobox_arenaID = "0",
		inflicted_damage = "52798",
		crafted = "160193",
		died = "13",
		punch_count = "4497",
		["stamina:poisoned"] = "no",
		placed_nodes = "62602",
		hud_state = "on",
		repellant = "0",
		yl_commons_player_created = "1621787993"
	}
}

Log identifier


[MOD] yl_report log identifier = tc7XQ4OLqWOc84CMqQLwRTSsYMth4upf

Profiler save:

profile-20220419T014609.json_prettyEE

Status:

# Server: version: 5.5.0-yl | game: Minetest Game | uptime: 8h 26min 48s | max lag: 3.17s | clients: Aleks555, LeetPeet, plod, pitman, flux, Oakenshield, Kiyoko, mindfrost, Sokomine, JeCel, shanish2, Service, Bailiff, Player249, AliasAlreadyTaken, GrimPixel

Teleport command:

/teleport xyz 845 4 1977

Compass command:

/give_compass Construction tc7XQ4OLqWOc84CMqQLwRTSsYMth4upf D2691E 845 4 1977

JeCel reports a bug: > Long Area lists (bottom left corner) are very disturbing. Would it be possible to implement a feature that let's you minimize that list? Player position: ``` { y = 3.5, x = 845.21105957031, z = 1976.5189208984 } ``` Player look: ``` { y = -0.057564023882151, x = -0.99549227952957, z = 0.075375534594059 } ``` Player information: ``` { min_rtt = 0.021999999880791, max_rtt = 0.53100001811981, connection_uptime = 12732, max_jitter = 0.48800000548363, minor = 4, major = 5, ip_version = 6, formspec_version = 4, patch = 1, protocol_version = 39, serialization_version = 28, lang_code = "", version_string = "5.4.1", avg_rtt = 0.027000000700355, state = "Active", avg_jitter = 0.0010000001639128, min_jitter = 0 } ``` Player meta: ``` { fields = { ["3d_armor_inventory"] = "return {\"3d_armor:helmet_crystal 1 22300\", \"3d_armor:chestplate_crystal 1 22420\", \"3d_armor:leggings_crystal 1 22300\", \"shields:shield_crystal 1 22300\", \"3d_armor:boots_crystal 1 26260\", \"\"}", yl_commons_thankyou = "4", jointime = "1621787993", yl_commons_player_joined = "1650312870", ["stamina:exhaustion"] = "9", digged_nodes = "356507", bitten = "0", ["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}", partychat = "party", yl_church = "return {[\"last_death\"] = {[\"y\"] = 16, [\"x\"] = 6198, [\"z\"] = 10043}}", played_time = "739307", ["stamina:level"] = "18", xp = "562496", arenalib_infobox_arenaID = "0", inflicted_damage = "52798", crafted = "160193", died = "13", punch_count = "4497", ["stamina:poisoned"] = "no", placed_nodes = "62602", hud_state = "on", repellant = "0", yl_commons_player_created = "1621787993" } } ``` Log identifier ``` [MOD] yl_report log identifier = tc7XQ4OLqWOc84CMqQLwRTSsYMth4upf ``` Profiler save: ``` profile-20220419T014609.json_prettyEE ``` Status: ``` # Server: version: 5.5.0-yl | game: Minetest Game | uptime: 8h 26min 48s | max lag: 3.17s | clients: Aleks555, LeetPeet, plod, pitman, flux, Oakenshield, Kiyoko, mindfrost, Sokomine, JeCel, shanish2, Service, Bailiff, Player249, AliasAlreadyTaken, GrimPixel ``` Teleport command: ``` /teleport xyz 845 4 1977 ``` Compass command: ``` /give_compass Construction tc7XQ4OLqWOc84CMqQLwRTSsYMth4upf D2691E 845 4 1977 ```

AliasAlreadyTaken was assigned by yourland-report

2022-04-18 23:46:09 +00:00

AliasAlreadyTaken added the

1. kind/enhancement

label 2022-04-18 23:55:33 +00:00

AliasAlreadyTaken added this to the 1.2 Cities and Invasions milestone 2022-04-18 23:55:36 +00:00

AliasAlreadyTaken commented

2022-04-18 23:59:12 +00:00

Sounds like the collapse areas feature in cities and invasions:

/areas_hud full|lite|collapse|none

full: Shows all areas.
lite: Shows always city, plot, or faction and a max of 3 other areas. If no city, then 4 of the topmost areas
collapse: Shows the existence of areas at this place
none: disables the areas hud altogether

Sounds like the collapse areas feature in cities and invasions: /areas_hud full|lite|collapse|none full: Shows all areas. lite: Shows always city, plot, or faction and a max of 3 other areas. If no city, then 4 of the topmost areas collapse: Shows the existence of areas at this place none: disables the areas hud altogether

AliasAlreadyTaken referenced this issue

2022-05-07 23:59:25 +00:00

LeetPeet reports: Could you implement a way for ... #1628

AliasAlreadyTaken referenced this issue

2022-05-23 08:08:04 +00:00

alexandre2005 reports: suggestion: add a command that ... #1963

AliasAlreadyTaken referenced this issue

2022-07-21 14:03:52 +00:00

annah reports: protected area side list sugge ... #2290

niceride commented

2022-10-22 15:06:57 +00:00

Is this documented anywhere in '/help' ?

flux commented

2022-10-22 16:29:15 +00:00

Is this documented anywhere in '/help' ?

the feature doesn't exist yet.

> Is this documented anywhere in '/help' ? the feature doesn't exist yet.

flux added the

2. prio/interesting

2. prio/elevated

labels 2022-10-27 00:51:21 +00:00

flux added a new dependency 2022-10-27 00:51:35 +00:00

your-land/administration#178 - interactive volumes

Sokomine commented

2022-12-13 22:02:13 +00:00

This has been a problem for many of us and has appeared multiple times in the bugtracker.

The suggested /areas_hud command may help, but it doesn't really solve the problem. It just hides it. And /areas_hud none conflicts too much with your desire to hurt the player if he/she accidentally protects a flower in a protected area.

The playerfactions mod could in theory be of help. Sadly it only allows one faction per user, and the way it's integrated into the areas mod does not allow any easy extension. Thus, that mod is useless for us.

However...even very active builders don't build in all towns all the time. I'd like to suggest the following command:
/area_add_me
This may sound strange at first - ups, a player can just add him/herself to an area?

But of course it's not planned to be that open. There shall be a list of player names stored for each area that are allowed to run the command. Thus we need /area_trust add/remove for maintaining this list and /area_trust without parameters to show/list who's allowed to run the command for this area. The list can be stored in the areas table.

Players who are part of the trusted player list of an area can run /area_add_me and get a normal standard subarea added - as if the owner of the area ran /add_owner <this_area_id> <this_player_name> <this_area_name>. Once they no londer need the area, they can remove it normally - or the owner of the parent area can remove it.

Of course humans are humans. We'd all forget most of the time to remove areas again that we currently don't need. Thus, when creating such an area with the /area_add_me, the time of creation shall be stored. After 3-7 days, the area can be removed automaticly again. If it's still needed, all the player would have to do is type /area_add_me as soon as he/she notices.

The benefit of this would be that the cities area lists could be limited to those that build there so often that a permanent area makes sense.

There's another side effect that needs to be taken care of: Shared ressources. There are public farms - those can be handled by setting an area to open. Shared chests and shared farms would be diffrent. A command
/area_shared
(similar to /area_open but allowing access to those in our list of trusted players only) could help.

Players who just need to build in a city occasionally may not even have to run /area_add_me each time if the area (ctiy) entire is set to shared. Regular building, digging and accessing chests can happen. Only when they need to create a new area for someone /area_add_me would be needed.

While /area_add_me and /area_trust may work independently of the areas mod (storing their data in the areas table would be highly recommended), /area_shared requires a small change to the areas mod. Even that might work with an external mod redefining the relevant protection function.

The other problem that remains are plots and masterareas. The current way to do it seems to create a new masterarea, add the desired plot owner to it, and then make the city account the owner of that subarea. This means that there are always two areas for a plot: The one owned by the city account and the one owned by the player who built there. While that may be fine for city plots in Haven and Aveniture, it is spammy and unnecessary in places where structures have been built and shall remain how they are. There could be only one area, marked as a city plot. The only difference would be that when the player who owns the plot deletes it it doesn't get deleted but instead returned to the city account who becomes the new owner. I'd like to have this, but this may also be more work than the ideas above.

City majors who'd want to use the system described here would have to create and maintain the list of trusted players for their city and set it to shared once. That way, those trusted players could still build in the city even after their subarea is removed from the list, and they can even add new areas when needed after typing /areas_add_me.

The disadvantage is that it's not immediately obvious who built what. But that's something the current system fails to show as well. The lists are too long.

Feedback desired!

This has been a problem for many of us and has appeared multiple times in the bugtracker. The suggested /areas_hud command may help, but it doesn't really solve the problem. It just hides it. And /areas_hud none conflicts too much with your desire to hurt the player if he/she accidentally protects a flower in a protected area. The *playerfactions* mod could in theory be of help. Sadly it only allows *one* faction per user, and the way it's integrated into the *areas* mod does not allow any easy extension. Thus, that mod is useless for us. However...even very active builders don't build in all towns all the time. I'd like to suggest the following command: /area_add_me This may sound strange at first - ups, a player can just add him/herself to an area? But of course it's not planned to be that open. There shall be a list of player names stored for each area that are allowed to run the command. Thus we need /area_trust add/remove <playername> for maintaining this list and /area_trust without parameters to show/list who's allowed to run the command for this area. The list can be stored in the areas table. Players who are part of the trusted player list of an area can run /area_add_me and get a normal standard subarea added - as if the owner of the area ran /add_owner <this_area_id> <this_player_name> <this_area_name>. Once they no londer need the area, they can remove it normally - or the owner of the parent area can remove it. Of course humans are humans. We'd all *forget* most of the time to remove areas again that we currently don't need. Thus, when creating such an area with the /area_add_me, the time of creation shall be stored. After 3-7 days, the area can be removed automaticly again. If it's still needed, all the player would have to do is type /area_add_me as soon as he/she notices. The benefit of this would be that the cities area lists could be limited to those that build there so often that a permanent area makes sense. There's another side effect that needs to be taken care of: Shared ressources. There are public farms - those can be handled by setting an area to open. Shared chests and shared farms would be diffrent. A command /area_shared (similar to /area_open but allowing access to those in our list of trusted players only) could help. Players who just need to build in a city occasionally may not even have to run /area_add_me each time if the area (ctiy) entire is set to *shared*. Regular building, digging and accessing chests can happen. Only when they need to create a new area for someone /area_add_me would be needed. While /area_add_me and /area_trust may work independently of the areas mod (storing their data in the areas table would be highly recommended), /area_shared requires a small change to the areas mod. Even that might work with an external mod redefining the relevant protection function. The other problem that remains are plots and masterareas. The current way to do it seems to create a new masterarea, add the desired plot owner to it, and then make the city account the owner of that subarea. This means that there are always *two* areas for a plot: The one owned by the city account and the one owned by the player who built there. While that may be fine for city plots in Haven and Aveniture, it is spammy and unnecessary in places where structures have been built and shall remain how they are. There could be only one area, marked as a city plot. The only difference would be that when the player who owns the plot deletes it it doesn't get deleted but instead returned to the city account who becomes the new owner. I'd like to have this, but this may also be more work than the ideas above. City majors who'd want to use the system described here would have to create and maintain the list of trusted players for their city and set it to shared once. That way, those trusted players could still build in the city even after their subarea is removed from the list, and they can even add new areas when needed after typing /areas_add_me. The disadvantage is that it's not immediately obvious who built what. But that's something the current system fails to show as well. The lists are too long. Feedback desired!

👍 2

Sokomine commented

2022-12-13 23:38:00 +00:00

Come to think of it, it might be sufficient to just have the command for sharing an area and maintaining the list of those people the area is shared with plus having those people beeing able to build and and access shared ressources (chests etc.) in that area. People able to add a plot to a city would then still need to hold a subarea. But at least it'd be clear whom to contact.

flux commented

2022-12-14 01:52:35 +00:00

@Sokomine i skimmed what you wrote, but i might be missing something.

my own thoughts:

only master areas (or city areas in a city) and a player's own sub-areas ought to be displayed
i dislike the idea of a command to toggle behavior. commands are deeply opaque to most users.
the markers:land_title_register ought to be used to get more info about the areas if someone needs to.

@Sokomine i skimmed what you wrote, but i might be missing something. my own thoughts: * only master areas (or city areas in a city) and a player's own sub-areas ought to be displayed * i dislike the idea of a command to toggle behavior. commands are deeply opaque to most users. * the `markers:land_title_register` ought to be used to get more info about the areas if someone needs to.

Sokomine commented

2022-12-17 20:20:15 +00:00

Planned solution for now:
Subareas can be marked as hidden by the owner of the master area and the owner of the area. That way the list shown in the HUD can be shortened. The owner of the master area is most able to decide which subareas/co-owners are most important to show to visitors.
People intrested can still see the entire area list with commands or a land title register.

Planned solution for now: Subareas can be marked as hidden by the owner of the master area and the owner of the area. That way the list shown in the HUD can be shortened. The owner of the master area is most able to decide which subareas/co-owners are most important to show to visitors. People intrested can still see the entire area list with commands or a land title register.

Sokomine referenced this issue

2022-12-23 05:10:35 +00:00

1.1.117 #3128

flux referenced this issue

2022-12-27 03:50:52 +00:00

1.1.117 #3128

Sokomine referenced this issue

2022-12-28 06:18:08 +00:00

1.1.117 #3128

flux referenced this issue

2022-12-28 16:40:50 +00:00

1.1.117 #3128

AliasAlreadyTaken referenced this issue

2023-01-12 04:50:01 +00:00

1.1.117 #3128

flux referenced this issue

2023-01-12 17:05:41 +00:00

1.1.117 #3128

AliasAlreadyTaken modified the milestone from 1.2 Cities and Invasions to 1.1.117

2023-01-17 08:58:18 +00:00

AliasAlreadyTaken added the

4. step/ready to QA test

label 2023-01-17 08:58:28 +00:00

AliasAlreadyTaken commented

2023-01-18 15:47:05 +00:00

Looks good :)

If this is meant to be yl-specific, we should have named the attribute yl_hide or something.
If the master area is forcefully removed, it only shows Areas: +3 subareas

I like that the default value is NOT to hide
In my opinion it is unfortunate that the areaowner governs what's to see on the client, instead of the client to decide what they want to see.
gitea notes a dependency on interactive volumes. This is not the case?

However, it works. Thankyou @flux and @Sokomine :)

Looks good :) 1. If this is meant to be yl-specific, we should have named the attribute yl_hide or something. 2. If the master area is forcefully removed, it only shows Areas: +3 subareas ![image](/attachments/b810ac91-0f41-4c73-8a0d-77d242b11475) 3. I like that the default value is NOT to hide 4. In my opinion it is unfortunate that the areaowner governs what's to see on the client, instead of the client to decide what they want to see. 5. gitea notes a dependency on interactive volumes. This is not the case? However, it works. Thankyou @flux and @Sokomine :)

image.png

13 KiB

👍 1

flux commented

2023-01-19 02:20:17 +00:00

If this is meant to be yl-specific, we should have named the attribute yl_hide or something.

i agree. i've changed the name in the following commits:

areas: 32db339ea4
yl_areas_addon: 861b7eabef

If the master area is forcefully removed, it only shows Areas: +3 subareas

i noticed that, but i'm not certain why that's happening. probably we should block until this this is fixed.

In my opinion it is unfortunate that the areaowner governs what's to see on the client, instead of the client to decide what they want to see.

we should revisit the issue in the future, because implementing per-player rules about what to hide and show is more complicated.

gitea notes a dependency on interactive volumes. This is not the case?

it's no longer the case cuz sokomine created a different fix than what i was planning. i'll remove it.

> 1. If this is meant to be yl-specific, we should have named the attribute yl_hide or something. i agree. i've changed the name in the following commits: * areas: https://gitea.your-land.de/your-land/areas/commit/32db339ea417dcae8ee75ae2b6683b8731de1700 * yl_areas_addon: https://gitea.your-land.de/your-land/yl_areas_addon/commit/861b7eabef2df25f77a7366d5a981c6562f039d9 > 2. If the master area is forcefully removed, it only shows Areas: +3 subareas > > ![image](/attachments/b810ac91-0f41-4c73-8a0d-77d242b11475) i noticed that, but i'm not certain why that's happening. probably we should block until this this is fixed. > 4. In my opinion it is unfortunate that the areaowner governs what's to see on the client, instead of the client to decide what they want to see. we should revisit the issue in the future, because implementing per-player rules about what to hide and show is more complicated. > 5. gitea notes a dependency on interactive volumes. This is not the case? it's no longer the case cuz sokomine created a different fix than what i was planning. i'll remove it.

flux removed a dependency 2023-01-19 02:20:23 +00:00

your-land/administration#178 - interactive volumes

Sokomine commented

2023-01-19 05:39:31 +00:00

i agree. i've changed the name in the following commits:

Changing the name is fine. yl_hidden serves the same purpose and makes it more clear that it's not part of upstream.

If the master area is forcefully removed, it only shows Areas: +3 subareas

If an area doesn't exist it isn't processed by the function that updates the HUD and cannot be shown. Each area is processed independently. Sure, this may be impractical when you're looking for which area this actually is. But there's still my markers mod with land title register. So it's possible to find out which area "got lost". Given that it's something that is useful for large cities, I think the majors can care about this. They have to anyway. And your own areas are always shown, no matter if they're hidden or not.

In my opinion it is unfortunate that the areaowner governs what's to see on the client, instead of the client to decide what they want to see.

What would we gain if the client can decide this? Sure, we could make it configurable. People would have to search where that config option is hidden, and those who find it by accident would be confused. Please see it as what it is: A tool for the majors to keep their cities playable without people with mobile clients having to flee due to beeing unable to read chat. Same as why people build roads or houses. What is presented and what isn't is the decision of those who can build there. It's not secret information anyway...the land title register exists. It's a service for visitors.

gitea notes a dependency on interactive volumes. This is not the case?

Unless areas or the yl areas addon depend on that - no. The areas mod has a function that updates the HUD. I changed that function and added functions to configure the yl_hidden attribute to yl_areas_addon.

> i agree. i've changed the name in the following commits: Changing the name is fine. yl_hidden serves the same purpose and makes it more clear that it's not part of upstream. > If the master area is forcefully removed, it only shows Areas: +3 subareas If an area doesn't exist it isn't processed by the function that updates the HUD and cannot be shown. Each area is processed independently. Sure, this may be impractical when you're looking for which area this actually is. But there's still my markers mod with land title register. So it's possible to find out which area "got lost". Given that it's something that is useful for large cities, I think the majors can care about this. They have to anyway. And your *own* areas are always shown, no matter if they're hidden or not. > In my opinion it is unfortunate that the areaowner governs what's to see on the client, instead of the client to decide what they want to see. What would we gain if the client can decide this? Sure, we could make it configurable. People would have to search where that config option is hidden, and those who find it by accident would be confused. Please see it as what it is: A tool for the majors to keep their cities playable without people with mobile clients having to flee due to beeing unable to read chat. Same as why people build roads or houses. What is presented and what isn't is the decision of those who can build there. It's not secret information anyway...the land title register exists. It's a service for visitors. > gitea notes a dependency on interactive volumes. This is not the case? Unless areas or the yl areas addon depend on that - no. The areas mod has a function that updates the HUD. I changed that function and added functions to configure the yl_hidden attribute to yl_areas_addon.

AliasAlreadyTaken added the

ugh/QA OK

label 2023-01-19 17:44:39 +00:00

AliasAlreadyTaken commented

2023-01-19 17:49:18 +00:00

What would we gain if the client can decide this?

There are arguments to be made that the client should decide what technical information they want. In the current iteration of the feature a smart area-owner must decide for everyone else, how the areas are displayed. This leads to a person who wants less areas displayed have no chance of having their wish fulfilled unless the area-owner complies. Which also demands they're still active. Had the client final say over how many areas are displayed, everyone could decide for themselves.

This is not only a tool for mayors - everyone should be able to use it on their private areas as well.

However, the way this works is nice as well. We'll add it.

> What would we gain if the client can decide this? There are arguments to be made that the client should decide what technical information they want. In the current iteration of the feature a smart area-owner must decide for everyone else, how the areas are displayed. This leads to a person who wants less areas displayed have no chance of having their wish fulfilled unless the area-owner complies. Which also demands they're still active. Had the client final say over how many areas are displayed, everyone could decide for themselves. This is not only a tool for mayors - everyone should be able to use it on their private areas as well. However, the way this works is nice as well. We'll add it.

Sokomine commented

2023-01-20 22:41:29 +00:00

Sure, it's always nicer to be able to configure things client-side. I'm just afraid it wouldn't gain users that much. If the major is inactive, there is still staff that might help if there's need. Not ideal, but then...not all things can be automatized.

flux commented

2023-01-25 16:57:51 +00:00

this is live.

now we just need to inform people about it, in particular LeetPeet =D

further discussion of tweaks to the behavior ought to be a new issue.

this is live. now we just need to inform people about it, in particular LeetPeet =D further discussion of tweaks to the behavior ought to be a new issue.

👍 4

flux closed this issue

2023-01-25 16:57:52 +00:00

Sign in to join this conversation.