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

Sokomine reports: just saw it now in another bug ... #4368

New Issue
Closed
opened 2023-04-30 21:48:46 +00:00 by yourland-report · 10 comments
yourland-report commented 2023-04-30 21:48:46 +00:00
Member
Copy Link

Sokomine reports a bug:

just saw it now in another bug report: trashed books get listed there with their content. that is...bad. imagine private books that would that way be published unintentionally. make the data from bug reports ingame less visible! it's enough when people who can actually do something can access the data when needed

Player position:

{
	x = 6580.9780273438,
	y = 3.5,
	z = 3052.1010742188
}

Player look:

{
	x = 0.9932821393013,
	y = 0.11302979290485,
	z = 0.02479531802237
}

Player information:

{
	formspec_version = 6,
	major = 5,
	version_string = "5.8.0-dev-d197ff0f9-dirty",
	lang_code = "",
	minor = 8,
	protocol_version = 41,
	ip_version = 6,
	min_rtt = 0.01799999922514,
	avg_rtt = 0.018999999389052,
	min_jitter = 0,
	max_jitter = 10.396999359131,
	avg_jitter = 0.0010000001639128,
	connection_uptime = 10615,
	serialization_version = 29,
	patch = 0,
	max_rtt = 10.619999885559,
	state = "Active"
}

Player meta:

{
	fields = {
		["3d_armor_inventory"] = "return {\"\", \"3d_armor:helmet_crystal 1 20\", \"shields:shield_rainbow 1 8\", \"3d_armor:chestplate_crystal 1 20\", \"3d_armor:boots_crystal 1 20\", \"3d_armor:leggings_crystal 1 20\"}",
		["ethereal:fly_timer"] = "-99",
		partychat = "main",
		["ocean_build.last_warning"] = "1.65032e+09",
		["ocean_build.ocean_built"] = "5",
		died = "42",
		jointime = "1617905120",
		played_time = "13352899",
		digged_nodes = "1845531",
		placed_nodes = "309986",
		inflicted_damage = "5042606",
		crafted = "555720",
		bitten = "0",
		repellant = "0",
		["signslib:pos"] = "(2247,-164,1417)",
		yl_commons_player_created = "1617905120",
		yl_commons_player_joined = "1682880736",
		xp = "2091650",
		hud_state = "on",
		punch_count = "242065",
		yl_commons_thankyou = "409",
		["stamina:level"] = "14",
		yl_church = "return {[\"last_death_portal\"] = 1681162650, [\"last_death\"] = {[\"x\"] = 2221, [\"z\"] = 1645, [\"y\"] = -139}, [\"last_heal\"] = 1673909657}",
		["stamina:poisoned"] = "no",
		yl_unified_trash_review = "return {\"default:book_written 1 0 \\\"\\\\u0001page_max\\\\u00021\\\\u0003text\\\\u0002leader: MineWorlds\\\\nshepherd: MineWorlds\\\\nother participants: Allen (first timer!), bizon, Chache, copper248, Ente, flux, fredercini (first timer!), mahou, Murmel, plotuss, set, Sokomine\\\\napologies if i missed anyone, i wasn't expecting to write this. \\\\n\\\\nthe move started out fairly calmly, though there were an *unusual* quantity of spies. first actual troops we encountered were a couple scout foci w/ eyes near DON'T PANIC, which we mostly avoided. we went around the west side of the wall. around 1/2 way along the n/s stretch, was an overseer w/ a cadre of about 15 blazes, which were quickly dispatched. at the end of the wall was another scout focus, which we avoided. there were 2 eyes, an overseer, and about 20 blazes, which didn't provide much resistance, but which set a lot of the terrain on fire. once that was clear, we moved forward, and met nothing but many more spies until near the north-west gate of FrostHall. \\\\n\\\\nat this point, there was a small focus on the far side of Dani no Katta me, which we ignored. but, outside frosthall's gate in the grass, and continuing all along the jungle rivers, was an absolute sea of whips. beyond the river were 3 micro foci, each w/ multiple eyes, and certainly already 100s of micros. while i tried to find a way around or through the micro foci, we were ambushed from behind by a few other micro and small foci w/ eyes. the miocene were turtled and a defensive perimeter was established. about this time, mahou sighed a dragon - a small \\\\\\\"tamed\\\\\\\" dragon, that seemed to be flying circles over the battle, but which then flew west over the jungle and disappeared. \\\\n\\\\ni decided that the easiest path forward would be to head west more, along a route that we've never actually used before. however, this still required clearing out a few score micros, which took time. i then learned why we rarely used that route - it had never been \\\\\\\"cleaned\\\\\\\" (it was covered w/ grass and other litter which make moving miocene messy), and it wended along narrow strips between several protection areas. we did, however, finally make it through, and encountered no more resistance.\\\\n\\\\nafter we'd turned in the miocene, we returned to the battlefield to finish off the remaining voice troops. at this point Sokomine sighted the dragon again, and then i did as well. i was able to pull the dragon out of the sky w/ a balrog whip, and dealt a fair amount of damage, but it escaped over the jungle to the north. \\\\n\\\\none additional thing i learned during this battle: vexes are apparently completely confused by water - if they are submerged, they can no longer fly or move at all. \\\\u0003page\\\\u00021\\\\u0003owner\\\\u0002flux\\\\u0003description\\\\u0002\\\\u001b(T@default)\\\\\\\"\\\\u001bFmiocene move of 2023-04-09\\\\u001bE\\\\\\\" by \\\\u001bFflux\\\\u001bE\\\\u001bE\\\\u0003title\\\\u0002miocene move of 2023-04-09\\\\u0003\\\"\", \"default:torch\", \"\", \"\"}",
		["stamina:exhaustion"] = "49",
		["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"water_life:croc_bag\"}",
		arenalib_infobox_arenaID = "0"
	}
}

Log identifier


[MOD] yl_report log identifier = RCjE5DVEOwGH5YVQDWyujJ1tCDHvTOKA

Profiler save:

profile-20230430T214846.json_prettyEE

Status:

# Server: version: 5.6.1-yl | game: Minetest Game | uptime: 7h 18min 10s | max lag: 1.63s | clients (37/52): AliasAlreadyTaken, AspireMint, Bailiff, biobee, bizon, BobaCat, Chameleon, Chazz, daydream, Dirac, drgn, Elias, Empempires, Flippster, flux, FullmetalBOI, Halvar, itaca94, johanlegend, laira, Laurii, legena, Lucien, mahou, niceride, NodeBreaker, rewired_X, rheo, Sandra, Scathach, Service, shanish3, Sokomine, Syslog, T-T-, the_chosen_one, Transformers

Teleport command:

/teleport xyz 6581 4 3052

Compass command:

/give_compass Construction RCjE5DVEOwGH5YVQDWyujJ1tCDHvTOKA D2691E 6581 4 3052
Sokomine reports a bug: > just saw it now in another bug report: trashed books get listed there with their content. that is...bad. imagine private books that would that way be published unintentionally. make the data from bug reports ingame less visible! it's enough when people who can actually *do* something can access the data when needed Player position: ``` { x = 6580.9780273438, y = 3.5, z = 3052.1010742188 } ``` Player look: ``` { x = 0.9932821393013, y = 0.11302979290485, z = 0.02479531802237 } ``` Player information: ``` { formspec_version = 6, major = 5, version_string = "5.8.0-dev-d197ff0f9-dirty", lang_code = "", minor = 8, protocol_version = 41, ip_version = 6, min_rtt = 0.01799999922514, avg_rtt = 0.018999999389052, min_jitter = 0, max_jitter = 10.396999359131, avg_jitter = 0.0010000001639128, connection_uptime = 10615, serialization_version = 29, patch = 0, max_rtt = 10.619999885559, state = "Active" } ``` Player meta: ``` { fields = { ["3d_armor_inventory"] = "return {\"\", \"3d_armor:helmet_crystal 1 20\", \"shields:shield_rainbow 1 8\", \"3d_armor:chestplate_crystal 1 20\", \"3d_armor:boots_crystal 1 20\", \"3d_armor:leggings_crystal 1 20\"}", ["ethereal:fly_timer"] = "-99", partychat = "main", ["ocean_build.last_warning"] = "1.65032e+09", ["ocean_build.ocean_built"] = "5", died = "42", jointime = "1617905120", played_time = "13352899", digged_nodes = "1845531", placed_nodes = "309986", inflicted_damage = "5042606", crafted = "555720", bitten = "0", repellant = "0", ["signslib:pos"] = "(2247,-164,1417)", yl_commons_player_created = "1617905120", yl_commons_player_joined = "1682880736", xp = "2091650", hud_state = "on", punch_count = "242065", yl_commons_thankyou = "409", ["stamina:level"] = "14", yl_church = "return {[\"last_death_portal\"] = 1681162650, [\"last_death\"] = {[\"x\"] = 2221, [\"z\"] = 1645, [\"y\"] = -139}, [\"last_heal\"] = 1673909657}", ["stamina:poisoned"] = "no", yl_unified_trash_review = "return {\"default:book_written 1 0 \\\"\\\\u0001page_max\\\\u00021\\\\u0003text\\\\u0002leader: MineWorlds\\\\nshepherd: MineWorlds\\\\nother participants: Allen (first timer!), bizon, Chache, copper248, Ente, flux, fredercini (first timer!), mahou, Murmel, plotuss, set, Sokomine\\\\napologies if i missed anyone, i wasn't expecting to write this. \\\\n\\\\nthe move started out fairly calmly, though there were an *unusual* quantity of spies. first actual troops we encountered were a couple scout foci w/ eyes near DON'T PANIC, which we mostly avoided. we went around the west side of the wall. around 1/2 way along the n/s stretch, was an overseer w/ a cadre of about 15 blazes, which were quickly dispatched. at the end of the wall was another scout focus, which we avoided. there were 2 eyes, an overseer, and about 20 blazes, which didn't provide much resistance, but which set a lot of the terrain on fire. once that was clear, we moved forward, and met nothing but many more spies until near the north-west gate of FrostHall. \\\\n\\\\nat this point, there was a small focus on the far side of Dani no Katta me, which we ignored. but, outside frosthall's gate in the grass, and continuing all along the jungle rivers, was an absolute sea of whips. beyond the river were 3 micro foci, each w/ multiple eyes, and certainly already 100s of micros. while i tried to find a way around or through the micro foci, we were ambushed from behind by a few other micro and small foci w/ eyes. the miocene were turtled and a defensive perimeter was established. about this time, mahou sighed a dragon - a small \\\\\\\"tamed\\\\\\\" dragon, that seemed to be flying circles over the battle, but which then flew west over the jungle and disappeared. \\\\n\\\\ni decided that the easiest path forward would be to head west more, along a route that we've never actually used before. however, this still required clearing out a few score micros, which took time. i then learned why we rarely used that route - it had never been \\\\\\\"cleaned\\\\\\\" (it was covered w/ grass and other litter which make moving miocene messy), and it wended along narrow strips between several protection areas. we did, however, finally make it through, and encountered no more resistance.\\\\n\\\\nafter we'd turned in the miocene, we returned to the battlefield to finish off the remaining voice troops. at this point Sokomine sighted the dragon again, and then i did as well. i was able to pull the dragon out of the sky w/ a balrog whip, and dealt a fair amount of damage, but it escaped over the jungle to the north. \\\\n\\\\none additional thing i learned during this battle: vexes are apparently completely confused by water - if they are submerged, they can no longer fly or move at all. \\\\u0003page\\\\u00021\\\\u0003owner\\\\u0002flux\\\\u0003description\\\\u0002\\\\u001b(T@default)\\\\\\\"\\\\u001bFmiocene move of 2023-04-09\\\\u001bE\\\\\\\" by \\\\u001bFflux\\\\u001bE\\\\u001bE\\\\u0003title\\\\u0002miocene move of 2023-04-09\\\\u0003\\\"\", \"default:torch\", \"\", \"\"}", ["stamina:exhaustion"] = "49", ["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"water_life:croc_bag\"}", arenalib_infobox_arenaID = "0" } } ``` Log identifier ``` [MOD] yl_report log identifier = RCjE5DVEOwGH5YVQDWyujJ1tCDHvTOKA ``` Profiler save: ``` profile-20230430T214846.json_prettyEE ``` Status: ``` # Server: version: 5.6.1-yl | game: Minetest Game | uptime: 7h 18min 10s | max lag: 1.63s | clients (37/52): AliasAlreadyTaken, AspireMint, Bailiff, biobee, bizon, BobaCat, Chameleon, Chazz, daydream, Dirac, drgn, Elias, Empempires, Flippster, flux, FullmetalBOI, Halvar, itaca94, johanlegend, laira, Laurii, legena, Lucien, mahou, niceride, NodeBreaker, rewired_X, rheo, Sandra, Scathach, Service, shanish3, Sokomine, Syslog, T-T-, the_chosen_one, Transformers ``` Teleport command: ``` /teleport xyz 6581 4 3052 ``` Compass command: ``` /give_compass Construction RCjE5DVEOwGH5YVQDWyujJ1tCDHvTOKA D2691E 6581 4 3052 ```
AliasAlreadyTaken was assigned by yourland-report 2023-04-30 21:48:46 +00:00
AliasAlreadyTaken commented 2023-04-30 22:11:19 +00:00
Owner
Copy Link

Having those values available, but not in public would require us to have two bugtrackers - an internal one and an external one.

But I agree the trashcan content shouldn't go to the bugtracker.

Having those values available, but not in public would require us to have two bugtrackers - an internal one and an external one. But I agree the trashcan content shouldn't go to the bugtracker.
AliasAlreadyTaken added the
1. kind/bug
3. source/integration
 labels 2023-04-30 22:11:26 +00:00
TheTrueBeginner commented 2023-05-01 09:54:07 +00:00
Member
Copy Link

So how should we fix this?

Disable bugtracker showing trashcan content completely or have two bugtrackers?

So how should we fix this? Disable bugtracker showing trashcan content completely or have two bugtrackers?
flux added the
2. prio/critical
 label 2023-05-02 00:58:46 +00:00
flux commented 2023-05-02 01:01:13 +00:00
Member
Copy Link

honestly, the player metadata is rarely if ever useful for debugging issues. maybe it's been useful, but i honestly don't remember when. i'd vote to record the data to disk in a way where alias could look it up by bug ID, and share the contents as necessary, but generally keep it private.

honestly, the player metadata is rarely if ever useful for debugging issues. maybe it's been useful, but i honestly don't remember when. i'd vote to record the data to disk in a way where alias could look it up by bug ID, and share the contents as necessary, but generally keep it private.
👍 2
AliasAlreadyTaken commented 2023-05-02 21:19:51 +00:00
Owner
Copy Link

In this case I'd rather have it in a second bugtracker that is private, but uses the same issue ID as the public one. We attempted such a thing a while back, but found its use very limited. But with yl_settings or worse, yl_quests, we need a way to take a nonpublic snapshot of a player anyways.

In this case I'd rather have it in a second bugtracker that is private, but uses the same issue ID as the public one. We attempted such a thing a while back, but found its use very limited. But with yl_settings or worse, yl_quests, we need a way to take a nonpublic snapshot of a player anyways.
flux commented 2023-05-03 02:33:32 +00:00
Member
Copy Link

In this case I'd rather have it in a second bugtracker that is private, but uses the same issue ID as the public one. We attempted such a thing a while back, but found its use very limited. But with yl_settings or worse, yl_quests, we need a way to take a nonpublic snapshot of a player anyways.

the idea of having multiple partially mirrored bug trackers "bugs" me - needing to keep track of 2 or more conversations about a single issue is troublesome.

but i could imagine a way to create an API to view current and historical player metadata (and yl_settings), and give staff a way of viewing it, and tying data @ specific points in time to issues in a way that only staff could see.

it'd be useful for staff to have a way to restrict people's access to view an issue or certain comments on an issue, but that's tricky and well outside gitea's featureset

> In this case I'd rather have it in a second bugtracker that is private, but uses the same issue ID as the public one. We attempted such a thing a while back, but found its use very limited. But with yl_settings or worse, yl_quests, we need a way to take a nonpublic snapshot of a player anyways. the idea of having multiple partially mirrored bug trackers "bugs" me - needing to keep track of 2 or more conversations about a single issue is troublesome. but i could imagine a way to create an API to view current and historical player metadata (and yl_settings), and give staff a way of viewing it, and tying data @ specific points in time to issues in a way that only staff could see. it'd be useful for staff to have a way to restrict people's access to view an issue or certain comments on an issue, but that's tricky and well outside gitea's featureset
AliasAlreadyTaken commented 2023-05-05 14:21:57 +00:00
Owner
Copy Link

That second bugtracker would hold conversation only in very few cases, when we want to have a nonpublic discussion. Most often, it would be used for reference.

Let's discuss elsewhere and keep this bug ontopic: Until a nonpublic bugtracker is ratified and available, let's disable trash from appearing here. In case questions arise, there's always the log.

Here to discuss public VS nonpublic bugtracker: #4407

That second bugtracker would hold conversation only in very few cases, when we want to have a nonpublic discussion. Most often, it would be used for reference. Let's discuss elsewhere and keep this bug ontopic: Until a nonpublic bugtracker is ratified and available, let's disable trash from appearing here. In case questions arise, there's always the log. Here to discuss public VS nonpublic bugtracker: #4407
AliasAlreadyTaken added this to the 1.1.119 milestone 2023-05-05 14:23:18 +00:00
AliasAlreadyTaken commented 2023-05-07 19:49:32 +00:00
Owner
Copy Link

Fixed in 3c59ee9573

Fixed in https://gitea.your-land.de/your-land/yl_report/commit/3c59ee957398b2ddf4dbc36c50b12c2337e1b818
AliasAlreadyTaken added the
4. step/ready to QA test
 label 2023-05-07 19:49:37 +00:00
AliasAlreadyTaken added the
ugh/QA OK
 label 2023-05-09 04:28:11 +00:00
AliasAlreadyTaken commented 2023-05-09 04:29:27 +00:00
Owner
Copy Link

QA

Trashcan doesn't go to reports nor bugtracker anymore.

Since I implemented it, could anyone look at the code or test and greenlight by 👍 ?

QA Trashcan doesn't go to reports nor bugtracker anymore. Since I implemented it, could anyone look at the code or test and greenlight by 👍 ?
flux commented 2023-05-09 22:13:49 +00:00
Member
Copy Link

i can't test it cuz i don't have a private gitea set up, but it looks correct.

style-wise, too many nil checks for my taste, but it'll work. player:get_meta() can return nil if the player has logged out, but we're getting player from minetest.get_player_by_name, so it will be fine. meta:to_table() will always return a table if the player object is valid, and will always contain a fields key.

i can't test it cuz i don't have a private gitea set up, but it looks correct. style-wise, too many `nil` checks for my taste, but it'll work. `player:get_meta()` can return `nil` if the player has logged out, but we're getting `player` from `minetest.get_player_by_name`, so it will be fine. `meta:to_table()` will *always* return a table if the player object is valid, and will always contain a `fields` key.
👍 1
flux added
5. result/fixed
 and removed
4. step/ready to QA test
 labels 2023-05-18 20:23:43 +00:00
AliasAlreadyTaken was unassigned by flux 2023-05-18 20:23:45 +00:00
flux commented 2023-05-18 20:23:56 +00:00
Member
Copy Link

this is live

this is live
flux closed this issue 2023-05-18 20:23:56 +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.119
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#4368
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?