whosit reports: Exploration rewards: there are ... #474

New Issue

yourland-report · 2021-04-19T20:50:34Z

yourland-report commented

2021-04-19 20:50:34 +00:00

whosit reports a bug:

Exploration rewards: there are many interesting places on the server, maybe reward people for finding them? It could be a special chest that gives player an item only first time they find it. Item can be random, or somethin special, maybe related to where the chest is: you climb a ship's mast and find a binoculars there etc.

Player position:

{
	y = 5.5009999275208,
	x = 2294.1989746094,
	z = 1116.8000488281
}

Player look:

{
	y = -0.99418860673904,
	x = -0.085222966969013,
	z = 0.065772883594036
}

Player information:

{
	min_rtt = 0.048000000417233,
	max_rtt = 0.47400000691414,
	connection_uptime = 1387,
	lang_code = "",
	address = "::ffff:109.252.94.126",
	formspec_version = 4,
	protocol_version = 39,
	avg_rtt = 0.050000000745058,
	min_jitter = 0,
	ip_version = 6,
	max_jitter = 0.42500001192093,
	avg_jitter = 0
}

Player meta:

{
	fields = {
		["3d_armor_inventory"] = "return {\"shields:shield_crystal 1 3040\", \"3d_armor:helmet_crystal 1 3040\", \"3d_armor:leggings_crystal 1 3040\", \"3d_armor:boots_crystal 1 2985\", \"3d_armor:chestplate_crystal 1 3040\", \"\"}",
		yl_commons_thankyou = "6",
		jointime = "1615221933",
		yl_commons_player_joined = "1618864081",
		["signslib:pos"] = "(25140,-38,30594)",
		digged_nodes = "43917",
		partychat = "party",
		yl_church = "return {[\"last_death\"] = {[\"y\"] = 4, [\"x\"] = 755, [\"z\"] = 1999}, [\"last_heal\"] = 1618069224, [\"last_death_portal\"] = 1618856822}",
		["stamina:level"] = "13.625",
		punch_count = "6950",
		inflicted_damage = "98766",
		crafted = "10929",
		played_time = "1093829",
		placed_nodes = "22030",
		died = "198",
		hud_state = "on",
		xp = "42169",
		yl_commons_player_created = "1615221933"
	}
}

Log identifier


[MOD] yl_report log identifier = 2kBFr6Zn8fh2NkRnvQMouPDoDm5Dw9Nv

Profiler save:

profile-20210419T225034.json_pretty

Status:

# Server: version=5.3.0-yl, uptime=58456.4, max_lag=1.92964, clients={Paso, LeetPeet, flux, Hydra, DragonsVolcanoDance, Mototank, Sokomine, Neo, boots, Zero, Vivianne, Finkyalashypoop, Boris, whosit, Oakenshield, Bailiff, Service, AliasAlreadyTaken, Ernesto}

whosit reports a bug: > Exploration rewards: there are many interesting places on the server, maybe reward people for finding them? It could be a special chest that gives player an item only first time they find it. Item can be random, or somethin special, maybe related to where the chest is: you climb a ship's mast and find a binoculars there etc. Player position: ``` { y = 5.5009999275208, x = 2294.1989746094, z = 1116.8000488281 } ``` Player look: ``` { y = -0.99418860673904, x = -0.085222966969013, z = 0.065772883594036 } ``` Player information: ``` { min_rtt = 0.048000000417233, max_rtt = 0.47400000691414, connection_uptime = 1387, lang_code = "", address = "::ffff:109.252.94.126", formspec_version = 4, protocol_version = 39, avg_rtt = 0.050000000745058, min_jitter = 0, ip_version = 6, max_jitter = 0.42500001192093, avg_jitter = 0 } ``` Player meta: ``` { fields = { ["3d_armor_inventory"] = "return {\"shields:shield_crystal 1 3040\", \"3d_armor:helmet_crystal 1 3040\", \"3d_armor:leggings_crystal 1 3040\", \"3d_armor:boots_crystal 1 2985\", \"3d_armor:chestplate_crystal 1 3040\", \"\"}", yl_commons_thankyou = "6", jointime = "1615221933", yl_commons_player_joined = "1618864081", ["signslib:pos"] = "(25140,-38,30594)", digged_nodes = "43917", partychat = "party", yl_church = "return {[\"last_death\"] = {[\"y\"] = 4, [\"x\"] = 755, [\"z\"] = 1999}, [\"last_heal\"] = 1618069224, [\"last_death_portal\"] = 1618856822}", ["stamina:level"] = "13.625", punch_count = "6950", inflicted_damage = "98766", crafted = "10929", played_time = "1093829", placed_nodes = "22030", died = "198", hud_state = "on", xp = "42169", yl_commons_player_created = "1615221933" } } ``` Log identifier ``` [MOD] yl_report log identifier = 2kBFr6Zn8fh2NkRnvQMouPDoDm5Dw9Nv ``` Profiler save: ``` profile-20210419T225034.json_pretty ``` Status: ``` # Server: version=5.3.0-yl, uptime=58456.4, max_lag=1.92964, clients={Paso, LeetPeet, flux, Hydra, DragonsVolcanoDance, Mototank, Sokomine, Neo, boots, Zero, Vivianne, Finkyalashypoop, Boris, whosit, Oakenshield, Bailiff, Service, AliasAlreadyTaken, Ernesto} ```

AliasAlreadyTaken was assigned by yourland-report

2021-04-19 20:50:34 +00:00

AliasAlreadyTaken added the

1. kind/enhancement

label 2021-04-22 11:54:04 +00:00

AliasAlreadyTaken commented

2021-04-22 11:54:29 +00:00

This can be done with the yl_quest API

flux commented

2023-03-06 00:24:06 +00:00

cf. #2689 (possibly a dupe)

whosit commented

2023-06-08 15:17:18 +00:00

I've made this:
https://gitea.your-land.de/whosit/collectible_chest

Yes, I've seen flux makes one.
Yes, I know there are many other versions around.

I did this to compare different ways of storing the mod data - modstorage vs sql.

It's still WIP, but all basic functions work, if anyone wishes to try it.

I've made this: https://gitea.your-land.de/whosit/collectible_chest Yes, I've seen flux makes one. Yes, I know there are many other versions around. I did this to compare different ways of storing the mod data - modstorage vs sql. It's still WIP, but all basic functions work, if anyone wishes to try it.

flux commented

2023-06-08 20:34:03 +00:00

to be fair, i never finished the version that i made.

whosit commented

2023-06-08 20:52:13 +00:00

to be fair, i never finished the version that i made.

Can I ask you what was the problem you encountered?

> to be fair, i never finished the version that i made. Can I ask you what was the problem you encountered?

flux commented

2023-06-08 20:53:44 +00:00

to be fair, i never finished the version that i made.

Can I ask you what was the problem you encountered?

mostly i got tired of fighting w/ formspecs. a lot of my projects die for the same reason.

> > to be fair, i never finished the version that i made. > > Can I ask you what was the problem you encountered? mostly i got tired of fighting w/ formspecs. a lot of my projects die for the same reason.

whosit commented

2023-06-08 21:03:44 +00:00

mostly i got tired of fighting w/ formspecs. a lot of my projects die for similar reasons.

Did you have a good idea for storing player_took_from_this_chest flag?
Because that's my main problem with this. If the requirement is thousand of chests and thousands of players, then storing this in meta or k/v modstorage becomes a problem.

> mostly i got tired of fighting w/ formspecs. a lot of my projects die for similar reasons. Did you have a good idea for storing player_took_from_this_chest flag? Because that's my main problem with this. If the requirement is thousand of chests and thousands of players, then storing this in meta or k/v modstorage becomes a problem.

flux commented

2023-06-08 22:26:48 +00:00

mostly i got tired of fighting w/ formspecs. a lot of my projects die for similar reasons.

Did you have a good idea for storing player_took_from_this_chest flag?
Because that's my main problem with this. If the requirement is thousand of chests and thousands of players, then storing this in meta or k/v modstorage becomes a problem.

hm. i didn't really get that far, but i've got an idea.

give each reward chest a unique ID. the "next available ID" can be stored as a single value in mod storage. each reward chest can store its ID in its own metadata. if you want to set the chests up so that they can be re-used by staff w/out having to place/break the chest, you can assign it a new ID every time an item is added to or removed from the chest.

when a player first interacts w/ a chest, they will get the items in the chest, and then we can set a value in player metadata to indicate that they've received the reward. the key would be something like string.format("reward_chest:%s", chest_id), and the value might just be true, or it could be a list of rewards from the chest that they have yet to claim.

> > mostly i got tired of fighting w/ formspecs. a lot of my projects die for similar reasons. > > Did you have a good idea for storing player_took_from_this_chest flag? > Because that's my main problem with this. If the requirement is thousand of chests and thousands of players, then storing this in meta or k/v modstorage becomes a problem. hm. i didn't really get that far, but i've got an idea. give each reward chest a unique ID. the "next available ID" can be stored as a single value in mod storage. each reward chest can store its ID in its own metadata. if you want to set the chests up so that they can be re-used by staff w/out having to place/break the chest, you can assign it a new ID every time an item is added to or removed from the chest. when a player first interacts w/ a chest, they will get the items in the chest, and then we can set a value in player metadata to indicate that they've received the reward. the key would be something like `string.format("reward_chest:%s", chest_id)`, and the value might just be `true`, or it could be a list of rewards from the chest that they have yet to claim.

whosit referenced this issue

2023-06-25 17:12:22 +00:00

flux reports: re-recreate the reward chest f ... #2689

flux referenced this issue

2023-06-26 00:13:43 +00:00

flux reports: re-recreate the reward chest f ... #2689

Sokomine commented

2023-06-26 17:35:09 +00:00

There ought to be a way to see how many reward chests the player has already found and how many are left.

Some kind of personal log would also be nice, although that comes with the danger that players would exchange/publish lists of locations - which would be rather bad.

Perhaps such chests ought to be placed only in newly added areas/buildings.

There ought to be a way to see how many reward chests the player has already found and how many are left. Some kind of personal log would also be nice, although that comes with the danger that players would exchange/publish lists of locations - which would be rather bad. Perhaps such chests ought to be placed only in newly added areas/buildings.

AliasAlreadyTaken commented

2023-06-27 01:36:11 +00:00

Those chests could also help in the tutorial. I like the idea to give all of them an ID and only store THAT in the meta, not the chest content itself.

Sokomine commented

2023-12-19 07:14:32 +00:00

What's the status on this issue?
Flux' mod seems to have suffered from formspec (very understandable, had to cobble plenty of virtual balrogs to death when writing the formspecs for the NPC).

Whosits' mod seems to work mostly. Sadly it's limited to one item per chest. Our problem is usually that we have more than one reward to hand out. Especially as quest rewards.

The original treasurechest mod by thefamilygrog66 can handle 8x4 items per treasure chest. That's much nicer to interact with as a player and feels much more like a chest. Drawback there is that it stores its data in map metadata. We don't really want that.

NPC also have trouble handing out more than one reward at a time. Alias mentionned yl_quest api? How's the status there?

Ideas/Wishes:

ability to hand out multiple diffrent stacks per reward/treasure...place (8x4, chest-like inventory, though most slots will be empty most of the time)
each player gets the rewards usually only once
automatic refill after some time of last taking could be an option
the player can take rewards from diffrent slots at diffrent times. That's important when the player doesn't have enough room in his inventory.
the player cannot put anything in the treasure chest and not move items around inside - just take part or all of it
NPC ought to be able to use the mechanism as well (as in: provide rewards/treasures this way - give them, not take treasures)
a way to keep track of which chests a player found. Can be done by having a list with a description of the area the chest is in - i.e. area name/description + area id, or which quest has it as reward
show how many players have found those chests in the list above
option for a chest/npc not to be listed in the list above (if it's i.e. a temporal event)
ID could be location of the chest as string or npc ID + time or set freely by the creator
once a treasure inventory has been created, it cannot be changed (because what gets stored is how many items the player took from each stack when - not what he took)
new treasure inventories can be created and be used by existing places; meaning: when a treasure is changed, all who accessed it in the past already can get the things from the new treasure again
if necessary, diffrent places can share the same treasure inventory
halfway efficient storage of data
keep in mind that very few players actually do quests and explore
a treasure chest right at spawn may be bad - that one would really attract many players and require storing a lot of data
store when a player first accessed a treasure inventory; the good old minetest.serialize/deserialize is not elegant but may be sufficient for the task

General data structure could be:
treasure_taken[treasure_inv_id][playername][treasure_inv_slot] = [amount_taken, time_when_last_taken]

What's the status on this issue? Flux' mod seems to have suffered from formspec (very understandable, had to cobble plenty of virtual balrogs to death when writing the formspecs for the NPC). Whosits' mod seems to work mostly. Sadly it's limited to one item per chest. Our problem is usually that we have more than one reward to hand out. Especially as quest rewards. The original [treasurechest](https://forum.minetest.net/viewtopic.php?t=13719) mod by thefamilygrog66 can handle 8x4 items per treasure chest. That's much nicer to interact with as a player and feels much more like a chest. Drawback there is that it stores its data in map metadata. We don't really want that. NPC also have trouble handing out more than one reward at a time. Alias mentionned yl_quest api? How's the status there? Ideas/Wishes: - ability to hand out multiple diffrent stacks per reward/treasure...place (8x4, chest-like inventory, though most slots will be empty most of the time) - each player gets the rewards usually only *once* - automatic refill after some time of last taking could be an option - the player can take rewards from diffrent slots at diffrent times. That's important when the player doesn't have enough room in his inventory. - the player cannot put anything in the treasure chest and not move items around inside - just take part or all of it - NPC ought to be able to use the mechanism as well (as in: provide rewards/treasures this way - give them, not take treasures) - a way to keep track of which chests a player found. Can be done by having a list with a description of the area the chest is in - i.e. area name/description + area id, or which quest has it as reward - show how many players have found those chests in the list above - option for a chest/npc not to be listed in the list above (if it's i.e. a temporal event) - ID could be location of the chest as string or npc ID + time or set freely by the creator - once a treasure inventory has been created, it *cannot* be changed (because what gets stored is how many items the player took from each stack when - not what he took) - new treasure inventories can be created and be used by existing places; meaning: when a treasure is changed, all who accessed it in the past already can get the things from the new treasure again - if necessary, diffrent places can share the same treasure inventory - halfway efficient storage of data - keep in mind that very few players actually do quests and explore - a treasure chest right at spawn may be bad - *that* one would really attract many players and require storing a lot of data - store when a player first accessed a treasure inventory; the good old minetest.serialize/deserialize is not elegant but may be sufficient for the task General data structure could be: treasure_taken[treasure_inv_id][playername][treasure_inv_slot] = [amount_taken, time_when_last_taken]

👍 1

whosit commented

2024-01-26 08:02:34 +00:00

One item per chest was a design decision to make storage simpler - basically just a flag per chest per player.
It works well for exploration rewards - you visit place once and take your treasure. If you really-really need two items, you could place 2 chests :) It seems simple and clean. It was also clean because I enforce a transaction of sorts - you either take all of your reward or none.

Of course, nothing really prevents us from having full inv for each chest and storing "leftover" inventory per chest. But what if you want to replace the contents? Soko's design decision is that you just can't. Other idea may be to store counts taken per slot.. With potential of turning 99 sticks into 98 diamonds or something, depending on implementation. The simplest idea could be just literally copying "master" inv for a specific player the moment they touch the chest and never change the copies, only master. Could slightly inflate the storage for chests with bad rewards people will never take...

I'm not sure "just a treasure chest you can find" is really the same chest that should be used for quests. Sure, some implementation details could be shared (efficient external storage for chest/quest to player mapping), but from the user standpoint, they should at least look different - so you know that one chest is just waiting for you to take stuff from it, and for other chest you need to fulfill some additional conditions...

Same with the global list - feels that just collectables and quests are kinda different, I would prefer having separate lists for them...

Maybe I should finish my original idea at least, then we can think if it fits or expands to more stuff....

(Soko loves big chests that can be filled with lots stuff... Maybe I should make this one microblock-sized to fit only one-slot inventory content)

One item per chest was a design decision to make storage simpler - basically just a flag per chest per player. It works well for exploration rewards - you visit place once and take your treasure. If you really-really need two items, you could place 2 chests :) It seems simple and clean. It was also clean because I enforce a transaction of sorts - you either take all of your reward or none. Of course, nothing really prevents us from having full inv for each chest and storing "leftover" inventory per chest. But what if you want to replace the contents? Soko's design decision is that you just can't. Other idea may be to store counts taken per slot.. With potential of turning 99 sticks into 98 diamonds or something, depending on implementation. The simplest idea could be just literally copying "master" inv for a specific player the moment they touch the chest and never change the copies, only master. Could slightly inflate the storage for chests with bad rewards people will never take... I'm not sure "just a treasure chest you can find" is really the same chest that should be used for quests. Sure, some implementation details could be shared (efficient external storage for chest/quest to player mapping), but from the user standpoint, they should at least look different - so you know that one chest is just waiting for you to take stuff from it, and for other chest you need to fulfill some additional conditions... Same with the global list - feels that just collectables and quests are kinda different, I would prefer having separate lists for them... Maybe I should finish my original idea at least, then we can think if it fits or expands to more stuff.... (Soko loves big chests that can be filled with lots stuff... Maybe I should make this one microblock-sized to fit only one-slot inventory content)

Sign in to join this conversation.